hi Thomas,
On Nov 27, 8:09am, Thomas Graichen wrote:
> Subject: Re: alpha again
> ...
> > (could you send me the output in each place - thanks).
> ...
everything looks good up till here...
> >> root@cyan:/usr/src/xfs/linux# mount /dev/sdb1 /mnt
> >> root@cyan:/usr/src/xfs/linux# umount /mnt
>
> > (*) here
>
> root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
> magicnum = 0
> versionnum = 4294967295
> seqno = 0
> length = 0
> bnoroot = 2966461184
> cntroot = 16580607
> bnolevel = 16580607
> cntlevel = 0
> flfirst = 2147483648
> fllast = 0
> flcount = 1088476165
> freeblks = 16580607
> longest = 14734341
> root@cyan:~#
>
heh - thats completely bogus. so the problem is in the kernel
(xfs mount/umount code paths) after all.
on the plus side, mkfs and repair both seem to be doing the
right thing.
> ...
> > I'm a little surprised that we can get thru dbench with what
> > seem like such fundamental problems... hmm - perhaps its only
> > a userspace problem (seeking to the wrong place or something).
it seems this is not the case.
my next best guess at the probable cause is that this may
be a blocksize related problem. we know that the primary
superblock is pretty much intact (otherwise xfs_db would have
gone haywire) - but since its offset is at start of blk 0,
we're always likely to get that right no matter what the page
& blksizes are, I think.
> yes - the filesystem as such runs perfectly so far - tell me if you
> need anything else
I need two more things, then I'll have to go read the code
some & get back to you:
- run "xfs_db -r -c sb -c p /dev/sdb1" after the mkfs, so I
know where we're starting from (primary sb);
- run "xfs_db -r -c agf -c p /dev/sdb1" again, but in-between
the mount and umount (there are writes on the mount path too,
with any luck we'll see corruption early on which should make
it easier to diagnose).
thanks!
--
Nathan
|