"Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> hi Thomas,
> 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?)
ok - here it is - sorry for the delay - i was a few days away:
df gave: blocks=3136128 used=11488 avail=3124640
blocksize from xfs_db is '524288'
xfs_db for /dev/hda9
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
> (btw, any luck with ppc mount detecting a minix filesystem?)
sorry- looks like this was my fault: minix fs was simply not compiled
into the kernel :-( ... works now
t
--
thomas.graichen@xxxxxxxxxxxxxx
technical director innominate AG
clustering & security the linux architects
tel: +49-30-308806-13 fax: -77 http://www.innominate.com
|