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
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
