[Yaffs] data loss under heavy pressure on Yaffs2 GC --> fix

[Charles Manning]

On Wednesday 03 August 2005 08:46, you wrote:

>
> It's not solved for my test.
> For nandemul2k:
> 	163(163 mod 256): TRUNCATE UP   from 0x2f56f to 0x3df9c ******WWWW
> 	164(164 mod 256): WRITE 0xe38d thru 0x14024     (0x5c98 bytes)
> 	165(165 mod 256): MAPWRITE 0x9fbc thru 0x18998  (0xe9dd bytes)
> 	166(166 mod 256): MAPWRITE 0x3ce3 thru 0xf9fa   (0xbd18 bytes)
> 	167(167 mod 256): MAPWRITE 0x9467 thru 0xed46   (0x58e0 bytes)
> 	168(168 mod 256): READ  0x1667 thru 0x2bcc      (0x1566 bytes)
> 	169(169 mod 256): WRITE 0x23bf3 thru 0x25a0b    (0x1e19 bytes)
> 	170(170 mod 256): WRITE 0x1e431 thru 0x1f186    (0xd56 bytes)
> 	171(171 mod 256): MAPWRITE 0x17363 thru 0x18e68 (0x1b06 bytes)
> 	172(172 mod 256): READ  0x31d03 thru 0x38bd1    (0x6ecf bytes)  ***RRRR***
>    The reference file contain all zero from 0x2f56f to 0x3df9c (= size of
> the file), this correspond to the TRUNCATE UP.
>    The test file have the same size, but contain data from 0x2f56f to
> 0x3a89d, the remaining are zeroes.
>    Seems to be a problem with the truncate.
>
> For nandsim:
>          662(150 mod 256): TRUNCATE DOWN from 0x3ecdd to 0x4dc   ******WWWW
>          663(151 mod 256): MAPWRITE 0x14745 thru 0x175a5 (0x2e61 bytes)
>          664(152 mod 256): READ  0x4f93 thru 0xab80      (0x5bee bytes)
>          665(153 mod 256): MAPWRITE 0x2b6af thru 0x39be4 (0xe536 bytes)
>          666(154 mod 256): MAPWRITE 0x2dc0 thru 0xeb74   (0xbdb5 bytes)
>          667(155 mod 256): TRUNCATE DOWN from 0x39be5 to 0x20817
>          668(156 mod 256): MAPWRITE 0x6b59 thru 0x143fe  (0xd8a6 bytes)
>          669(157 mod 256): TRUNCATE UP   from 0x20817 to 0x2bbb4
>          670(158 mod 256): MAPREAD       0xd930 thru 0x168a4     (0x8f75
> bytes)  ***RRRR*** Both files have a size of 0x2bbb4 (last TRUNCATE UP).
>    the reference file have data from 0x... to 0x143fe and zeroes from
> 0x143ff to 0x14745, and the data again;
>    while the test file have data till 0x144db, then zeroes from 0x144dc to
> 0x14745 and then data again.
>
>
> 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.

To summarize what you report here, the problem is that you'd expect to see 
holes in the file due to the resize.

Can you run this with more tracing on and see what happens inside YAFFS? 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