+++ This bug was initially created as a clone of Bug #240584 +++ [root@marathon-01 ~]# mount /dev/sdb1 /uss_a/ [root@marathon-01 ~]# cp -aR /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64 /uss_a/ [root@marathon-01 ~]# df -hi /uss_a Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb1 245M 25K 245M 1% /uss_a [root@marathon-01 ~]# df -h /uss_a Filesystem Size Used Avail Use% Mounted on /dev/sdb1 977G 374M 977G 1% /uss_a [root@marathon-01 ~]# mkfs.gfs2 -p lock_nolock -j 1 -O -r 2048 /dev/sdb1 Device: /dev/sdb1 Blocksize: 4096 Device Size 976.57 GB (256001791 blocks) Filesystem Size: 976.57 GB (256001791 blocks) Journals: 1 Resource Groups: 489 Locking Protocol: "lock_nolock" Lock Table: "" [root@marathon-01 ~]# df -hi /uss_a Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb1 245M 25K 245M 1% /uss_a [root@marathon-01 ~]# df -h /uss_a Filesystem Size Used Avail Use% Mounted on /dev/sdb1 977G 374M 977G 1% /uss_a [root@marathon-01 ~]# umount /uss_a ![root@marathon-01 ~]# mount /dev/sdb1 /uss_a/ [root@marathon-01 ~]# df -h /uss_a Filesystem Size Used Avail Use% Mounted on /dev/sdb1 977G 34M 977G 1% /uss_a [root@marathon-01 ~]# df -hi /uss_a Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb1 245M 12 245M 1% /uss_a [root@marathon-01 ~]# ls /uss_a [root@marathon-01 ~]# Most mkfs's that I know of will refuse to mkfs a mounted filesystem... mkfs.gfs[1] behaves the same way. -- Additional comment from cfeist on 2007-05-18 12:21 EST -- Re-assigning to rpeterso. -- Additional comment from rpeterso on 2007-05-18 13:30 EST -- This is essentially the same as the age-old bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156012 except that's for fsck whereas this is for mkfs. But we need the same mechanism for all the userland-only tools. The problem is tricky and we've had many discussions about it. It would be simple to figure out if the node that's doing mkfs has the fs mounted, but that isn't good enough, since other nodes may have it mounted as well. Figuring out if another node has a fs already mounted is difficult because when mkfs is run, you may not even have the cluster infrastructure running. In other words, you may not have any of the cluster communication stuff running at that point, and the userland tools can't be dependent on them running. In RHEL4 it was nearly impossible because much of the infrastructure was in the kernel code. In RHEL5, it might be somewhat easier because much of that code was brought down into userland. Today, a node will only have knowledge of the mount group only after it joins the group in question. We talked, for example, about changing the group code (gfs2_controld, groupd, etc.) so that all nodes know about the mount groups of other nodes, but that would be a potentially major design change. In theory, I suppose we could also have mkfs / fsck / etc. try to join the mount group first. If joining is successful, it could see if anyone else is a member of the group and if so, throw up an error. If it can't join, it could throw up a warning saying something like (but less wordy than): "WARNING: The cluster infrastructure isn't running, so %s can't tell if the file system is mounted by other nodes. Are you sure you still want to do this operation and have you made sure no other node has the thing mounted?", argv[0] We could also throw in a check for the lock protocol and have it be more forgiving if lock_nolock was specified in the superblock. We could have it check only in the local /proc/mounts, etc., although that's not very good either because the mount protocol may have been overridden on the mount command from another node. There was some promising discussion about using exclusive volume locking stuff in LVM2. However, that only solves the problem for LVM2 volumes, and there are customers out there using GFS and GFS2 with no clustered LVM in place, so just raw devices. We could call that a permanent restriction. I suppose some checking is better than none at all, which is what we have right now. I'm going to reroute this to Ryan O'Hara since he's got the original bug and since I'm going on vacation and can't work on it. I'd understand if Ryan closes it as a duplicate of that bug. I'm also adding Dave Teigland to the cc list because he's been a part of the discussion since day one. -- Additional comment from teigland on 2007-05-18 13:56 EST -- It's a no-brainer to check if the fs is mounted on the local node, which solves the problem for lock_nolock which is what was reported here. Just check what mkfs.ext3 does (could it be as simple as using O_EXCL?) and copy it. That would probably catch a lot of lock_dlm cases, too. For checking if the fs is mounted on another node, we've been through all those discussions over and over, and my position hasn't changed -- the only thing that makes sense is to activate the LV exclusively. Yes, you are required to use clvm to benefit from some ancillary cluster-related features of GFS (see withdraw); this is simply one of them. -- Additional comment from rohara on 2007-07-10 14:10 EST -- Fixed. Added check_mount function to gfs_mkfs/main.c, which does a very simple scan of /proc/mounts using the getmntent() interface. If we see that the device is already mounted, simple print an error message and exit. Please note that this check can only determine if a device is locally mounted. It will not solve the other issue, where another node may have the device mounted. -- Additional comment from esandeen on 2007-07-10 14:13 EST -- Thanks, sounds good. Yes, I understand that cross-SAN mount checks are tricky. ext3 could use it too. :) -Eric -- Additional comment from rohara on 2007-07-10 14:26 EST -- This is fixed for gfs and gfs2. My previous comment is in reference to the code changes for gfs(1). Changes for gfs2 are in gfs2/mkfs/main_mkfs.c. Code is identical.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This check only works in the case that the same device name is used as is in /proc/mounts. This isn't the case for LVM2 devices. The /dev/VG/LV devices show up in /proc/mounts as /dev/mapper/VG-LV. [root@morph-01 ~]# mkfs -t gfs -p lock_nolock /dev/morph-cluster/morph-cluster0 -j 1 This will destroy any data on /dev/morph-cluster/morph-cluster0. It appears to contain a gfs filesystem. Are you sure you want to proceed? [y/n] y Device: /dev/morph-cluster/morph-cluster0 Blocksize: 4096 Filesystem Size: 182210968 Journals: 1 Resource Groups: 2782 Locking Protocol: lock_nolock Lock Table: Syncing... All Done [root@morph-01 ~]# mount /dev/morph-cluster/morph-cluster0 /mnt/morph-cluster0 [root@morph-01 ~]# mkfs -t gfs -p lock_nolock /dev/morph-cluster/morph-cluster0 -j 1 This will destroy any data on /dev/morph-cluster/morph-cluster0. It appears to contain a gfs filesystem. Are you sure you want to proceed? [y/n] y Device: /dev/morph-cluster/morph-cluster0 Blocksize: 4096 Filesystem Size: 182210968 Journals: 1 Resource Groups: 2782 Locking Protocol: lock_nolock Lock Table: Syncing... All Done [root@morph-01 ~]# cat /proc/mounts ... /dev/mapper/morph--cluster-morph--cluster0 /mnt/morph-cluster0 gfs rw,localflocks,localcaching,oopses_ok 0 0 [root@morph-01 ~]# mkfs -t gfs -p lock_nolock /dev/mapper/morph--cluster-morph--cluster0 -j 1 cannot create filesystem: /dev/mapper/morph--cluster-morph--cluster0 appears to be mounted [root@morph-01 ~]# ls -l /dev/mapper/morph--cluster-morph--cluster0 /dev/morph-cluster/morph-cluster0 brw-rw---- 1 root disk 253, 2 Apr 18 13:19 /dev/mapper/morph--cluster-morph--cluster0 lrwxrwxrwx 1 root root 42 Apr 18 13:15 /dev/morph-cluster/morph-cluster0 -> /dev/mapper/morph--cluster-morph--cluster0
Fixed for 5.3 Changed how the check_mount() function works in gfs_mkfs. Instead of using getmntent, the code will now open the device with the O_EXCL flag. If the device is mounted (or busy), errno will be set to EBUSY and gfs_mkfs exits. Note that this change will also prevent users from running gfs_mkfs on a device that belongs to a volume group. This fix will only work on kernel version 2.6 and above.
Verified with gfs-utils-0.1.18-1.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0059.html