Hi Andre

Did you dig into that whole vmtruncate() calling sequence that we discussed in 
October?

YAFFS runs fine with a hacked up version of fsx using yaffs direct. I have 
discussed this a person who used fsx a lot and he said that fsx is good for 
kicking up cache inconsistencies.

I hunch that is what is happening here: Likely the page cache is not being 
cleared properly.

-- Charles

On Tuesday 02 October 2007 08:09:56 Andre Renaud wrote:
> When running fsx (file system exerciser, from freebsd/apple -
> http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/regression/fsx/), we are
> seeing some failures when doing truncate operations. The behaviour seems
> to be:
> Open a new file
> Write some data
> truncate the file so that it is shorter
> truncate it so that it is larger - the intervening space should be all
> nuls (see ftruncate manpage).
> Write some data at the new end of the file, thus leaving the hole in the
> middle.
>
> fsx complains that the intervening space is not-nul.
>
> I haven't been able to write a straight forward test case, so it is
> possible that this bug is intermittent, or my interpretation of the fsx
> output is wrong.
>
> Also, the problem seems to go away if I force fsx to only truncate onto
> page boundaries (multiples of 2048 bytes).
>
> I used the following command line to trigger the failure:
>  ./fsx -N 10000 /mnt/foo
>
> I've attached the output of fsx, although the relevant parts are the top:
> READ BAD DATA: offset = 0xdd7c, size = 0xd933
> OFFSET  GOOD    BAD     RANGE
> 0x f000 0x0000  0x6c22  0x  7fc
>
> and the bottom:
> 9602(130 mod 256): MAPREAD      0x2d86c thru 0x382f1    (0xaa86 bytes)
> 9603(131 mod 256): TRUNCATE DOWN        from 0x3c5fd to 0xb013  ******WWWW
> 9604(132 mod 256): WRITE        0x19606 thru 0x282e0    (0xecdb bytes)
> HOLE     ***WWWW
> 9605(133 mod 256): WRITE        0x1d4e2 thru 0x1dfd5    (0xaf4 bytes)
> 9606(134 mod 256): MAPREAD      0xdd7c thru 0x1b6ae     (0xd933 bytes)
> ***RRRR***
>
> This indicates that at offset 0xf000, it was expecting to read nuls
> (GOOD: 0x0000), but it read non null (BAD: 0x6c22), having done a
> truncate down to 0xb013,
>
> Does anyone know about anything like this?
> Andre