Bug 492932 - GFS2: umount hung after grow
GFS2: umount hung after grow
Status: CLOSED DUPLICATE of bug 469773
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Robert Peterson
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-30 16:01 EDT by Nate Straz
Modified: 2009-05-27 23:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-31 10:12:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nate Straz 2009-03-30 16:01:34 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:
Comment 1 Robert Peterson 2009-03-31 09:19:36 EDT
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.
Comment 2 Nate Straz 2009-03-31 09:30:35 EDT
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.
Comment 3 Nate Straz 2009-03-31 09:33:00 EDT
I was able to reproduce this yesterday while omitting #4.
Comment 4 Robert Peterson 2009-03-31 10:12:51 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.