[Linux-cluster] Incomplete gfs2_fsck aborting without error

[Jeff Sturm]

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 at redhat.com
[mailto:linux-cluster-bounces at redhat.com]
> On Behalf Of Tom Lanyon
> Sent: Wednesday, May 26, 2010 10:07 PM
> To: linux clustering
> Subject: Re: [Linux-cluster] 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster