[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] gfs 6.1 superblock backups

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.


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]