Red Hat Bugzilla – Bug 492932
GFS2: umount hung after grow
Last modified: 2009-05-27 23:38:18 EDT
Description of problem: After filling and growing a small file system, umounting a GFS2 filesystem hangs. Version-Release number of selected component (if applicable): kernel-2.6.18-137.el5 How reproducible: Every time Steps to Reproduce: 1. lvcreate -n grow -L 2G vg 2. mkfs -t gfs2 -j 1 -p lock_nolock -O /dev/vg/grow 3. mount -t gfs2 /dev/vg/grow /mnt/grow 4. dd if=/dev/zero of=/mnt/grow/loadfile bs=10k & 5. lvextend -L +2G /dev/vg/grow 6. gfs2_grow /mnt/grow 7. umount /mnt/grow 8. *HANG* Actual results: The umount hangs. Expected results: The umount should not hang Additional info:
When you ran this, did you have the fix for bug #469773 on your system? Following the exact same commands, but using the latest and greatest gfs2 code (almost--2.6.18-137 kernel) compiled from the RHEL5 branch of the cluster git tree, I was not able to recreate the problem. Unmount said, "/sbin/umount.gfs2: /mnt/gfs2: device is busy." until the dd ran out of space on the device, then the unmount worked properly. The gfs2_grow, however, did not work because it complained that it had grown too little, and maybe that's why I was able to unmount.
No, I did not have the fix for 469773, but I wasn't able to recreate that bug either. When I ran the testcase, #4 would fill the file system before I got to #6.
I was able to reproduce this yesterday while omitting #4.
This works for me, as long as I have the fix for bug #469733 on my system, with or without the dd. A stupid typing blunder caused my earlier problem I reported. [root@roth-01 ../bob/cluster/gfs2/mkfs]# lvcreate -n grow -L 2G roth_vg Logical volume "grow" created [root@roth-01 ../bob/cluster/gfs2/mkfs]# mkfs -t gfs2 -j 1 -p lock_nolock -O /dev/roth_vg/grow Device: /dev/roth_vg/grow Blocksize: 4096 Device Size 2.00 GB (524288 blocks) Filesystem Size: 2.00 GB (524288 blocks) Journals: 1 Resource Groups: 8 Locking Protocol: "lock_nolock" Lock Table: "" UUID: 8B632434-093F-879D-E081-B2DE8BCCBF68 [root@roth-01 ../bob/cluster/gfs2/mkfs]# mount -t gfs2 /dev/roth_vg/grow /mnt/gfs2 [root@roth-01 ../bob/cluster/gfs2/mkfs]# lvextend -L +2G /dev/roth_vg/grow Extending logical volume grow to 4.00 GB Logical volume grow successfully resized [root@roth-01 ../bob/cluster/gfs2/mkfs]# gfs2_grow /mnt/gfs2 FS: Mount Point: /mnt/gfs2 FS: Device: /dev/mapper/roth_vg-grow FS: Size: 524288 (0x80000) FS: RG size: 65533 (0xfffd) DEV: Size: 1048576 (0x100000) The file system grew by 2048MB. gfs2_grow complete. [root@roth-01 ../bob/cluster/gfs2/mkfs]# umount /mnt/gfs2 [root@roth-01 ../bob/cluster/gfs2/mkfs]# lvremove -f /dev/roth_vg/grow Logical volume "grow" successfully removed I'm going to close this as a duplicate of bug #469773 although some of your comments indicate you may have also run into bug #490649. I guess the summary of #469733 indicates block sizes other than 4K, if the file system is small enough, the miscalculations can still cause the problem on small file systems. I'll append a comment to that affect to that bz. I know the fix for bug #469733 has not made it to a build yet, but perhaps we can get one built for testing so you can verify this fixes the problem. If it doesn't, feel free to re-open the bz. *** This bug has been marked as a duplicate of bug 469773 ***