[Linux-cluster] error messages while use fsck.gfs2

Steven Whitehouse swhiteho at redhat.com
Wed Nov 16 14:25:06 UTC 2011


Hi,

On Wed, 2011-11-16 at 19:44 +0530, Rajagopal Swaminathan wrote:
> Greetings,
> 
> On Wed, Nov 16, 2011 at 7:13 PM, Bob Peterson <rpeterso at redhat.com> wrote:
> > ----- Original Message -----
> > The latest/greatest upstream fsck.gfs2 has the ability to recreate
> > pretty much any and all damaged system structures and system files,
> > but there's only so much it can do. That's why I suggested trying the
> > experimental RHEL6 version, which isn't too far out of date from
> > the upstream version. It's much better at recovering single blocks
> > that have been overwritten, rather than a group of blocks. It's
> > actually quite sophisticated in recreating things.
> >
> 
> Well, can't we (the Redhat/Centos fanboys) expect a critical Clustered
> filesystem like GFS2 (Which supports over 16TB on a 64-bit bit systems
> at least) take a leaf or two from () ZFS on this issue?
> 
I'm not quite sure which feature you are suggesting that we take, but
I'd be surprised that if the start of a ZFS filesystem were to be
overwritten that it could be easily reconstructed.

The problem here is "how much is enough?". If we kept the first 8 blocks
of the fs duplicated, then someone would come along and overwrite the
first 16 and them say why did you choose only 8? We could duplicate
everything, but then why not simply mirror at the block device level?

Which is not to say that we couldn't usefully learn a few lessons from
what other filesystems are doing, but only that I'm not sure that it
would help for this particular issue.

> Of course, I don't support misuse of "dd" on any critical system by
> anybody. I will make sure that they will not been seen within 100KM
> radius near that cluster after doing that. Though I am not vindictive,
> I will "hunt them, chase them" and whatever. Even an alcoholic/drug
> addict does not do that.
> 
> Well, above just my IMHO.
> 

Steve.





More information about the Linux-cluster mailing list