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.
(text/plain)