> On Thu, Jul 19, 2001 at 09:15:15AM +0200, Wolfgang Henselmann-Weiss wrote:
> >
> > syslog output is ...
> > |Jul 19 09:08:48 wolfi kernel: XFS: SB sanity check 2 failed
> > |Jul 19 09:08:48 wolfi kernel: XFS: SB validate failed
> >
>
> Hmmm ... that looks grim - the error comes from here, in the
> XFS kernel code (xfs_mount.c):
>
> if (sbp->sb_dblocks == 0 ||
> sbp->sb_dblocks >
> (xfs_drfsbno_t)sbp->sb_agcount * sbp->sb_agblocks ||
> sbp->sb_dblocks < (xfs_drfsbno_t)(sbp->sb_agcount - 1) *
> sbp->sb_agblocks + XFS_MIN_AG_BLOCKS) {
> cmn_err(CE_WARN, "XFS: SB sanity check 2 failed");
> return XFS_ERROR(EFSCORRUPTED);
> }
>
> So, it seems mkfs might be coming up with bad data.. haven't ever
> seen that before. Could you run xfs_db on the device, and print
> the superblock & send us that? Something like:
>
> # xfs_db -c sb -c p /dev/foo
>
> and we should be able to narrow it down to one of those 3 condition.
>
> thanks.
>
> --
> Nathan
OK, this is very interesting, the mkfs output:
|wolfi:/etc # mkfs.xfs -f /dev/hde7
|meta-data=/dev/hde7 isize=256 agcount=16, agsize=262144 blks
|data = bsize=4096 blocks=3932200, imaxpct=25
| = sunit=0 swidth=0 blks, unwritten=0
|naming =version 2 bsize=4096
|log =internal log bsize=4096 blocks=1200
|realtime =none extsz=65536 blocks=0, rtextents=0
This shows that mkfs picked an allocation group size which left a very small
allocation group at the end of the filesystem. You have 16 allocation groups,
16 * 262144 = 4194304 file system blocks, but you only actually have 3932200
blocks. 15 allocation groups take 3932160 leaving a huge 40 blocks for the
last one, this fails the test in the mount code which Nathan posted.
You could fool mkfs into thinking the device is slightly smaller for now
by doing this:
mkfs -t xfs -f -d 3932160b /dev/hde7
I think this will then mount. Clearly mkfs should not be building a
filesystem which does not mount!
Steve
|