Bug 595488
| Summary: | gfs2_grow /dev/gfs2_vg/lv0 gfs2_grow: Filesystem /dev/gfs2_vg/lv0 is not GFS2. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Shane Bradley <sbradley> | ||||||
| Component: | gfs2-utils | Assignee: | Robert Peterson <rpeterso> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 5.5 | CC: | adas, bmarzins, edamato, rpeterso, swhiteho, tao | ||||||
| Target Milestone: | rc | Keywords: | Regression | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | gfs2-utils-0.1.62-25.el5 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 597002 (view as bug list) | Environment: | |||||||
| Last Closed: | 2011-01-13 23:20:39 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 597002 | ||||||||
| Attachments: |
|
||||||||
I have a theory that this occurred when the code for checking that the fs was mounted was moved out of the gfs2_grow code into libgfs2. I'd suggest moving the code back into gfs2_grow and fixing the bug. The history in git doesn't go back far enough to confirm this though. My fear is that this patch may have regressed us: http://git.fedoraproject.org/git/?p=cluster.git;a=commitdiff;h=59cdde95dbad76b573eb93b88fb7e69ca0b7a9ea I was planning to check that but my RHEL5 boxes have been tied up with my other work, so I haven't yet taken the time. That looks like the first step. Having said that, the issue here appears to be that having sorted out whether we've been passed a block device or a mount point, that info isn't passed back to the app from the library. Okay, I just took the time. My theory is confirmed. The problem is a regression introduced by the patch given in comment #3. We need to adjust that patch to identify gfs2 devices by device major and minor as well. But care must be taken so that we don't break the regress the bug we were fixing with that patch. Created attachment 417398 [details]
Proposed patch
This patch fixes the problem. I don't have a good way to test
whether it breaks anything else at the moment.
The patch was tested on system roth-01. I tested fsck.gfs2, gfs2_tool, gfs2_jadd, gfs2_grow, mkfs.gfs2, on both <mntpt> and <device>. All tests worked as expected. The fix was pushed to the upstream cluster git tree. Changing status to POST until it's built. Build 2768496 successful. Changing status to Modified. This fix is in gfs2-utils-0.1.62-25.el5. Note that the patch in distcvs is named after the RHEL6.0 crosswrite: bz597002.patch Verified against gfs2-utils-0.1.62-28.el5.
[root@dash-01 ~]# mkfs -t gfs2 -O -p lock_dlm -j 3 -t dash:grow /dev/dash/grow
Device: /dev/dash/grow
Blocksize: 4096
Device Size 10.00 GB (2621440 blocks)
Filesystem Size: 10.00 GB (2621438 blocks)
Journals: 3
Resource Groups: 40
Locking Protocol: "lock_dlm"
Lock Table: "dash:grow"
UUID: 7B72795D-FB43-7ADD-EAD7-608D1064778D
[root@dash-01 ~]# mount /dev/dash/grow /mnt/grow
[root@dash-01 ~]# lvextend -L +10G dash/grow
Extending logical volume grow to 20.00 GB
Logical volume grow successfully resized
[root@dash-01 ~]# gfs2_jadd -j 2 /mnt/grow
Filesystem: /mnt/grow
Old Journals 3
New Journals 5
[root@dash-01 ~]# gfs2_jadd -j 2 /dev/dash/grow
Filesystem: /mnt/grow
Old Journals 5
New Journals 7
[root@dash-01 ~]# gfs2_grow /dev/dash/grow
FS: Mount Point: /mnt/grow
FS: Device: /dev/mapper/dash-grow
FS: Size: 2621438 (0x27fffe)
FS: RG size: 65535 (0xffff)
DEV: Size: 5242880 (0x500000)
The file system grew by 10240MB.
gfs2_grow complete.
[root@dash-01 ~]# lvextend -L +10G dash/grow
Extending logical volume grow to 30.00 GB
Logical volume grow successfully resized
[root@dash-01 ~]# gfs2_grow /mnt/grow
FS: Mount Point: /mnt/grow
FS: Device: /dev/mapper/dash-grow
FS: Size: 5242838 (0x4fffd6)
FS: RG size: 65535 (0xffff)
DEV: Size: 7864320 (0x780000)
The file system grew by 10240MB.
gfs2_grow complete.
[root@dash-01 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
66G 1.7G 61G 3% /
/dev/sda1 99M 18M 77M 19% /boot
tmpfs 2.5G 0 2.5G 0% /dev/shm
/dev/mapper/dash-grow
30G 905M 29G 3% /mnt/grow
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-2011-0135.html |
Created attachment 416199 [details] This is strace of $(gfs2_grow /dev/gfs2_vg/lv0) after I did the 2nd extend of the lv. Description of problem: If a device(lvm device) path is used to grow a gfs2 filesystem then an error will occur. gfs2_grow will work if mountpoint path is used: Node information: $ uname -a Linux rh5node1 2.6.18-194.el5xen #1 SMP Tue Mar 16 22:01:26 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep gfs2-utils gfs2-utils-0.1.62-20.el5 Extend the logical volume by 150 extends: $ lvextend -l +150 /dev/gfs2_vg/lv0 Extending logical volume lv0 to 1.59 GB Logical volume lv0 successfully resized $ vgdisplay gfs2_vg | grep "Free PE" Free PE / Size 92 / 368.00 MB $ lvs gfs2_vg/lv0 LV VG Attr LSize Origin Snap% Move Log Copy% Convert lv0 gfs2_vg -wi-ao 1.59G Now try and grow the GFS2 fs $ mount | grep gfs2 /dev/mapper/gfs2_vg-lv0 on /mnt/demoGFS2 type gfs2 \ (rw,hostdata=jid=0:id=131073:first=1) $ gfs2_grow /dev/gfs2_vg/lv0 gfs2_grow: Filesystem /dev/gfs2_vg/lv0 is not GFS2. Here is superblock information: $ gfs2_edit -p sb /dev/gfs2_vg/lv0 Block #16 (0x10) of 415744 (0x65800) (superblock) Superblock: mh_magic 0x01161970(hex) mh_type 1 0x1 mh_format 100 0x64 sb_fs_format 1801 0x709 sb_multihost_format 1900 0x76c sb_bsize 4096 0x1000 sb_bsize_shift 12 0xc master dir: 2 0x2 addr: 23 0x17 root dir : 1 0x1 addr: 22 0x16 sb_lockproto lock_dlm sb_locktable rh5cluster1:mygfs2 sb_uuid 2B6A0E2B-0332-0E51-52C0-5EEFC9F212AD The superblock has 2 directories 1. (1). 22 (0x16): Dir root 2. (2). 23 (0x17): Dir master Grow works if you use the "mount point" path $ mount | grep gfs2 /dev/mapper/gfs2_vg-lv0 on /mnt/demoGFS2 type gfs2 \ (rw,hostdata=jid=0:id=262145:first=1) $ gfs2_grow /mnt/demoGFS2 FS: Mount Point: /mnt/demoGFS2 FS: Device: /dev/mapper/gfs2_vg-lv0 FS: Size: 262142 (0x3fffe) FS: RG size: 65531 (0xfffb) DEV: Size: 415744 (0x65800) The file system grew by 600MB. gfs2_grow complete. ---- SUCCESS: $ gfs2_grow /mnt/demoGFS2 FAILS: $ gfs2_grow /dev/gfs2_vg/lv0 Version-Release number of selected component (if applicable): gfs2-utils-0.1.62-20.el5 How reproducible: Everytime Steps to Reproduce: 1. Mount GFS2 fs that is a logical volume 2. Extend the logical volume 3. Try to grow the GFS2 fs while mounted: $ gfs2_grow /dev/gfs2_vg/lv0 Actual results: gfs2_grow errors out when "device name" is passed to command. Passing the "mount point" will work. $ gfs2_grow /dev/gfs2_vg/lv0 gfs2_grow: Filesystem /dev/gfs2_vg/lv0 is not GFS2. Expected results: gfs2_grow should grow the fs if "device name" is passed to it. Additional info: Attached an strace of gfs2_grow