On Nov 15, 9:37am, Thomas Graichen wrote:
> Subject: Re: stress test on ppc
> > 004 - this looks like a 32 bit number overflow in the xfs_db
> > "freesp" command, i'll need to investigate a bit more.
going through this one again - this doesn't look like a
bug in xfs_db after all (the xfs_db output in the .bad
file looks correct).
(cmd/xfs/stress/004 on ppc produced...)
QA output created by 004
Checking blocks column same as df: no (204776407040 != 1599815680)
Error: /dev/hda9: freesp mismatch: no (204776407040 != 1599815680)
xfs_db output ...
from to extents blocks pct
1 1 4 4 0.00
32768 49152 8 390576 100.00
total free extents 12
total free blocks 390580
average free extent size 32548.3
Checking percent column yields 100: 100
so, xfs_db gave us a total free blocks value of 390580,
which multiplied by the blocksize (4096) gives 1599815680.
df gave us an "avail" value of 1599815680, which all looks
correct - the question is, where did 204776407040 come from??
either the initial blocksize calculation is incorrect,
or perl on ppc is doing some very funky math. can you
figure out what the blocksize gets calculated as? (i've
changed the test to create a 004.full with this info in -
could you rerun the test & send me that?)
(btw, any luck with ppc mount detecting a minix filesystem?)