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
--
Bluewater Systems Ltd - ARM Technology Solutions Centre
Andre Renaud Bluewater Systems Ltd
Phone: +64 3 3779127 (Aus 1 800 148 751) Level 17, 119 Armagh St
Fax: +64 3 3779135 PO Box 13889
Email: arenaud@bluewatersys.com Christchurch
Web: http://www.bluewatersys.com New Zealand
(text/plain)