|
Description
|
The file stress test utility "fsx" (attached) blows chunks on Solaris Intel;
the issue appears to be with reads from holes which appear to return
non-0 when they should return 0. truss(1) seems to indicate that the program
is right:
fxstat(2, 3, 0x08046FD0) = 0
lseek(3, 0, SEEK_END) = 49724
fcntl(3, F_FREESP, 0x08047014) = 0
typ=F_WRLCK whence=SEEK_SET start=49401 len=0 sys=8192 pid=50
<ftruncate to 49401>
fxstat(2, 3, 0x08046FD0) = 0
lseek(3, 0, SEEK_END) = 49401
fcntl(3, F_FREESP, 0x08047014) = 0
typ=F_WRLCK whence=SEEK_SET start=175498 len=0 sys=0 pid=-1078985
7
31
another ftruncate <49401-175498> now all 0.
fxstat(2, 3, 0x08046FD0) = 0
lseek(3, 0, SEEK_END) = 175498
fcntl(3, F_FREESP, 0x08047014) = 0
typ=F_WRLCK whence=SEEK_SET start=115960 len=0 sys=8192 pid=96
truncate to 115960
fxstat(2, 3, 0x08046FD0) = 0
lseek(3, 0, SEEK_END) = 115960
lseek(3, 58563, SEEK_SET) = 58563
read(3, 0x080E8E58, 5571) = 5571
<all 0 read as expected>
fxstat(2, 3, 0x08046FD0) = 0
lseek(3, 0, SEEK_END) = 115960
lseek(3, 213273, SEEK_SET) = 213273
seeking to 213273
write(3, "\b90DD90CB90AC90D690E290".., 33887) = 33887
size now 213273 + 33887
but 49401-213273 0s
fxstat(2, 3, 0x08046FD0) = 0
lseek(3, 0, SEEK_END) = 247160
lseek(3, 117231, SEEK_SET) = 117231
read(3, 0x080E8E58, 5883) = 5883
<this read returns non-NULL data at offset 0x1d000 (118784)>
The bad offset appear to always be at odd 4K boundaries; this seems to
indicate that there is a problem with page fills on odd boundaries beacuse
the size of the page (4K) is not the same as the size of a block (8K) and
the second page of a hole block is not zerod as it should.
To test this theory I created a 4K blocksize filesystem using lofi; this
filesystem generated no errors even though the test was run for a very
long time.
To get the best trace results use: "fsx -RW ufsfile"
Casper
|
