Bug 189462 - Request for automatic umount of full snapshots
Request for automatic umount of full snapshots
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2 (Show other bugs)
5.5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Rockai
Corey Marthaler
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-20 04:10 EDT by Olle Liljenzin
Modified: 2011-07-21 08:28 EDT (History)
8 users (show)

See Also:
Fixed In Version: lvm2-2.02.84-1.el5
Doc Type: Enhancement
Doc Text:
This field is the basis of the errata or release note for this bug. It can also be used for change logs. The Technical Note template, known as CCFR, is as follows: Cause Snapshot filling in with a mounted filesystem. Consequence The mounted filesystem becomes unusable, reporting large number of errors. Fix When a snapshot fills up, the filesystem is now automatically unmounted. Result When a snapshot fills up, any mounted filesystem will be forcibly unmounted, avoiding lookup/read/write errors.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-21 06:51:24 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 Olle Liljenzin 2006-04-20 04:10:01 EDT
Description of problem:
The file system on a shapshot will get broken if the snapshot gets full because
of writes to the original device.

It is not possible to mount a snapshot after it has been full and deactivated,
but a snapshot that was mounted before it was full will remain mounted.

I see two major issues with the current behaviour to not unmount snapshots when
they get full:

1. Kernel crashes because of broken file system. Of course, a kernel shouldn't
crash because of this, but we have seen it several times in RHEL4.

2. Corrupt data can sometimes be read from the broken file system without read
errors. This could e.g. result in inconsistent backups if snapshots are used for
this.

Version-Release number of selected component (if applicable):
lvm2-2.02.01-1.3.RHEL4

How reproducible:
Always on a system with reasonable disk activity

Steps to Reproduce:
1. Create a snapshot of a disk with some regular activity
2. Mount the snapshot readonly
3. Do something else for a few days
  
Actual results:
fs errors are reported to the console
kernel crashes with panic, oops or similar

Expected results:
The deactivated shapshot should be unmounted. The snapshot device should be
completely unavailable, i.e. all read operations should fail.
Comment 1 Milan Broz 2008-01-03 07:53:54 EST
This depends on dmeventd snapshot dso - it should extend snaphot if there is no
space or unmout fs and deactivate snapshot if there is no space available.
Comment 2 Milan Broz 2010-05-14 18:41:58 EDT
Moving this feature request (I mean extending snapshot automatically from monitoring DSO) to RHEL5.
Comment 3 Petr Rockai 2010-10-05 10:51:39 EDT
A patch for the "extend" part of the functionality has been posted for review. For the umount, I have the approach sorted out in my head, shouldn't be much of a problem to implement & post tomorrow. --> assigned.
Comment 4 Petr Rockai 2010-10-28 19:14:16 EDT
Just a status update: the patch for this has been posted, but the initial version was deemed insufficient. Two things need to be changed here: move the umount out of the dmeventd mutex (I have done this part) and replace a call to umount2 with forking /bin/umount to get /etc/mtab updated automatically. I haven't done this yet, but it's fairly easy, so there should be a workable patch soon.
Comment 5 Petr Rockai 2010-10-29 10:28:03 EDT
Current proposed patch at http://www.redhat.com/archives/lvm-devel/2010-October/msg00367.html
Comment 8 Milan Broz 2011-03-01 10:10:14 EST
> We also need to silence the recurring "trying to umount" message that Corey reported on IRC a couple days back

Please fix that.
Comment 9 Petr Rockai 2011-03-02 06:10:28 EST
Well, it has been fixed in CVS two weeks ago.
Comment 12 Milan Broz 2011-03-08 09:34:20 EST
Should be already in
lvm2-2.02.84-1.el5
Comment 14 Corey Marthaler 2011-05-09 17:35:01 EDT
Verified that a full mounted snapshot gets unmounted in the latest rpms.

2.6.18-256.el5

lvm2-2.02.84-2.el5    BUILT: Wed Mar 23 07:18:08 CDT 2011
lvm2-cluster-2.02.84-2.el5    BUILT: Wed Mar 23 07:19:43 CDT 2011
device-mapper-1.02.63-2.el5    BUILT: Fri Mar  4 10:23:17 CST 2011
device-mapper-event-1.02.63-2.el5    BUILT: Fri Mar  4 10:23:17 CST 2011
cmirror-1.1.39-10.el5    BUILT: Wed Sep  8 16:32:05 CDT 2010
kmod-cmirror-0.1.22-3.el5    BUILT: Tue Dec 22 13:39:47 CST 2009



# before full
[root@taft-01 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       57G  1.6G   53G   3% /
/dev/sda1              99M   18M   77M  19% /boot
tmpfs                 4.0G     0  4.0G   0% /dev/shm
/dev/mapper/taft-origin
                     1008M  491M  467M  52% /mnt/origin
/dev/mapper/taft-snap1
                     1008M  491M  467M  52% /mnt/snap1

# after full
[root@taft-01 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       57G  1.6G   53G   3% /
/dev/sda1              99M   18M   77M  19% /boot
tmpfs                 4.0G     0  4.0G   0% /dev/shm
/dev/mapper/taft-origin
                     1008M  100M  858M  11% /mnt/origin


May  9 16:28:21 taft-01 dmeventd[13408]: dmeventd ready for processing.
May  9 16:28:21 taft-01 lvm[13408]: Monitoring snapshot taft-snap1
May  9 16:29:05 taft-01 kernel: EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
May  9 16:30:56 taft-01 kernel: device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception.
May  9 16:30:56 taft-01 lvm[13408]: Unmounting invalid snapshot taft-snap1 from /mnt/snap1.
May  9 16:30:58 taft-01 kernel: Buffer I/O error on device dm-3, logical block 0
May  9 16:30:58 taft-01 kernel: lost page write due to I/O error on dm-3
May  9 16:30:58 taft-01 restorecond: Reset file context /etc/mtab: root:object_r:lvm_metadata_t:s0->system_u:object_r:etc_runtime_t:s0
Comment 16 Florian Nadge 2011-05-26 10:51:54 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
This field is the basis of the errata or release note for this bug. It can also be used for change logs.

The Technical Note template, known as CCFR, is as follows:

Cause
    What actions or circumstances cause this bug to present.
Consequence
    What happens when the bug presents.
Fix
    What was done to fix the bug.
Result
    What now happens when the actions or circumstances above occur.
    Note: this is not the same as the bug doesn’t present anymore.
Comment 17 Petr Rockai 2011-05-30 04:07:39 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -3,11 +3,10 @@
 The Technical Note template, known as CCFR, is as follows:
 
 Cause
-    What actions or circumstances cause this bug to present.
+    Snapshot filling in with a mounted filesystem.
 Consequence
-    What happens when the bug presents.
+    The mounted filesystem becomes unusable, reporting large number of errors.
 Fix
-    What was done to fix the bug.
+    When a snapshot fills up, the filesystem is now automatically unmounted.
 Result
-    What now happens when the actions or circumstances above occur.
+    When a snapshot fills up, any mounted filesystem will be forcibly unmounted, avoiding lookup/read/write errors.-    Note: this is not the same as the bug doesn’t present anymore.
Comment 18 errata-xmlrpc 2011-07-21 06:51:24 EDT
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-1071.html
Comment 19 errata-xmlrpc 2011-07-21 08:28:29 EDT
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-1071.html

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