One possible issue with gfs_grow: Make sure all cluster nodes see the increased block device size before you grow the filesystem. This should be automatic if you use CLVM, but other types of devices (iSCSI) may require intervention. We've used gfs_grow successfully, but do not run any GFS2 filesystems. Just a guess, but it sounds like gfs2_grow failed, left the filesystem in an inconsistent state, and fsck.gfs2 was able to repair it. > -----Original Message----- > From: linux-cluster-bounces@xxxxxxxxxx [mailto:linux-cluster-bounces@xxxxxxxxxx] > On Behalf Of Tom Lanyon > Sent: Wednesday, May 26, 2010 10:07 PM > To: linux clustering > Subject: Re: Incomplete gfs2_fsck aborting without error > > On 27/05/2010, at 11:00 AM, Tom Lanyon wrote: > > > > Hi Bob, > > > > Thanks. This reveals a number of errors (directory entries pointing to out of range > blocks, wrong leaf counts, blocks marked wrong in the bitmap and a couple of > unrecoverable inode errors). It's a little scary that these sorts of errors aren't > discovered by the regular fsck! > > > > This disk was grown at some point so I assume this problem occurred as a result of > the filesystem extension, could this be "GFS2: fatal: invalid metadata block after > gfs2_grow (BZ#546683)" ? > > Sorry to reply to my own post, but after Bob's new fsck.gfs2 was successfully run and > the filesystem was remounted, it's actually now reporting its *old* size. > > i.e. > - the block device and gfs2 fs were 70GB; > - the block device was grown to 100GB, then gfs2_grow was run and the filesystem > reported 100GB too; > - encountered ENOSPC errors; > - unmount, run Bob's "fsck.gfs2 -y /dev/xvdb" and re-mount the filesystem; > - filesystem now reporting 70GB total space; > > Is this a known issue? > > Regards, > Tom > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
