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.
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.
Moving this feature request (I mean extending snapshot automatically from monitoring DSO) to RHEL5.
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.
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.
Current proposed patch at http://www.redhat.com/archives/lvm-devel/2010-October/msg00367.html
> We also need to silence the recurring "trying to umount" message that Corey reported on IRC a couple days back Please fix that.
Well, it has been fixed in CVS two weeks ago.
Should be already in lvm2-2.02.84-1.el5
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
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.
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.
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