[Linux-cluster] gfs 6.1 superblock backups

[Wendy Cheng]

Bob Peterson wrote:
> On Tue, 2008-06-03 at 13:27 -0500, Chris Adams wrote:
>   
>> Bob and Wendy, 
>> Thank you for your input on this.  What I am trying to do 
>> is upgrade a GFS 6.0 filesystems which are attached to various 
>> RHEL3/CentOS3 systems.  After performing the steps which outline the 
>> process of going from 3 to 4, but on a CentOS 5 system, I get the problems 
>> mentioned in my message yesterday Re: /sbin/mount.gfs thinks fs is gfs2?  
>> Everyt time I reinstalled a system with CentOS 5 and tried to get gfs 
>> running again I got the same error.
>>
>> Since I know that this is an unsupported operation, I haven't sought 
>> support for this.  However, I noticed that my upgraded filesystem had 
>> sb_fs_format = 1308.  The mount code checks for sb_fs_format == 
>> GFS_FORMAT_FS for gfs 6.1 and GFS2_FORMAT_FS for gfs2.  Since it was 
>> neither of these, it kept dying saying that it was a gfs2 fs when mounting 
>> it as gfs, and vice versa.  Manually modifying sb_fs_format allowed it to 
>> mount immediately afterward.  A subsequent gfs_fsck completes all passes 
>> successfully.  
>>
>> Is that sufficient for upgrading the filesystem if the other steps are 
>> performed?  All fs operations appear to be successful at this point.
>>
>> thanks,
>> -chris
>>     
>
> I can't think of a good reason why my predecessors would have changed
> the file system format ID unless there was something in the file system
> that changed and needed reorganizing or reformatting. 
I'm not the person who added this ID but it is a *right* thing to do. As 
a rule of thumb, when moving between major releases, such as RHEL3 and 
RHEL4, a filesystem needs to have an identifier to facilitate the 
upgrade process. There should be documents, commands and/or tools to 
guide people how to do the upgrade - all require this type of "ID" 
implementation. And there should be associated testing efforts allocated 
to the upgrade command as a safe guard before you can call a filesystem 
"enterprise product". For GFS specifically, the locking protocols are 
different between GFS 6.0 and 6.1 (e.g. GULM is in RHEL3 but not in 
RHEL4) and locking protocol is part of the superblock structure, iirc.

 From practical point of view, it is probably ok to keep going (but do 
check RHEL manuals - there should be chapters talking about migration 
and upgrade between RHEL3 to 4 and RHEL4 to 5).

 From process point of view, this looks like a RHEL5 bug to me.

-- Wendy