Message-Id: <200107191439.f6JEdcd31931@jen.americas.sgi.com>
To: Nathan Scott <nathans@sgi.com>
cc: Wolfgang Henselmann-Weiss <Wolfgang_Henselmann@betaresearch.de>,
   Daniel Moore <dxm@snort.melbourne.sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS problems 
In-Reply-To: Message from Nathan Scott <nathans@sgi.com> 
   of "Thu, 19 Jul 2001 21:33:48 +1000." <20010719213347.A196344@wobbly.melbourne.sgi.com> 
Date: Thu, 19 Jul 2001 09:39:38 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 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