Re: [Yaffs] FSX issues on YAFFS2 - truncate on non-page boun…

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: yaffs
Subject: Re: [Yaffs] FSX issues on YAFFS2 - truncate on non-page boundaries
I'm pretty sure this is because when truncating a file, yaffs does not call
vmtruncate() which leaves some mapped pages in the vm cache.

Try adding         


        if (ivalid & ATTR_SIZE && inode->i_size > attr->ia_size)
                vmtruncate(inode, attr->ia_size);


before the return in yaffs_setattr()

-- CHarles



On Tuesday 09 October 2007 14:40:52 Andre Renaud wrote:
> Just to add to this - the same results happen when using non-mmap
> reads/writes (-R & -W to fsx). Results:
> READ BAD DATA: offset = 0x2f5dc, size = 0xa930
> OFFSET  GOOD    BAD     RANGE
> 0x2f5dc 0x0000  0xd76c  0x   78
> ....
> 493(237 mod 256): READ  0x68f2 thru 0x11c70     (0xb37f bytes)
> 494(238 mod 256): WRITE 0x7c8e thru 0x1604a     (0xe3bd bytes)
> 495(239 mod 256): READ  0x14eca thru 0x1ea7a    (0x9bb1 bytes)
> 496(240 mod 256): READ  0x84eb thru 0x156c4     (0xd1da bytes)
> 497(241 mod 256): TRUNCATE DOWN from 0x1ea7b to 0x5120
> 498(242 mod 256): READ  0x35b8 thru 0x511f      (0x1b68 bytes)
> 499(243 mod 256): WRITE 0x388ee thru 0x3ffff    (0x7712 bytes) HOLE
> ***WWWW
> 500(244 mod 256): READ  0x2f5dc thru 0x39f0b    (0xa930 bytes)  ***RRRR***

>
> So it did a read @0x2f5dc, which should have been a hole in the file
> (after the truncate down to 0x5120), but it got back non-zero data.
>
> Andre
>
> Andre Renaud wrote:
> <snip>
>
> > I've attached the truncated 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