Luc Van Oostenryck wrote:
> Charles Manning wrote:
> 
>> On Wednesday 03 August 2005 08:46, you wrote:
>>
>>
>>> It's not solved for my test.
> 
> 
>>> It seems that there is a problem with resizing.
>>>
>>> Luc
>>
>>
>>
>>
>> So this happens in a single run without any unmount/mount between the 
>> writing and the reading?  If so, then it is not the problem fixed in 
>> 1.15 which required a rescan to make the problem happen.
> 
> 
> Yes, it happen whithout remounting (the content of the test file don't 
> change
> after a reboot, it's still corrupted).
> 
>> To summarize what you report here, the problem is that you'd expect to 
>> see holes in the file due to the resize.
> 
> 
> The hole are an optimization (no block physically written), but yes it 
> is expected
> to read back zeroes.
> 
>> Can you run this with more tracing on and see what happens inside YAFFS?
> 
> 
> Yes, I'll do. It should be better to have a smaller specific testcase.
> I
> 
>> don't want to point any fingers yet (not until I see a trace log), but 
>> it could be the Linux page cache holding onto data and this being 
>> given back. Perhaps there is some page invalidation that needs to 
>> happen that is not happening? Perhaps some page is not being released 
>> at the correct time?
>>
>> -- Charles
>>
> 
> Yes, this is certainly a possibility, I will compare with the other file 
> systems
> to see what they do with the pages after a truncate/resize.
> 
> 
> Luc
> 

Yes, there seems to be something missing.

The others fs use something like a mix of calling vmtruncate() and/or something like the code below,
either in setattr() or XXX_truncate() (to add in inode_operations and called by vmtruncate if present)

	page = grab_cache_page(inode->i_mapping, inode->i_size >> PAGE_CACHE_SHIFT) // or attrs->ia_size  >> PAGE_CACHE_SHIFT
	// if needed, fill with zeroes the partial page
	// there is already a/some function to do this
	flush_dcache_page(page);
	unlock_page(page);
	page_cache_release(page);


I will need to investigate much further.