Bug 88115
| Summary: | error mounting lvm ext3 snapshot | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Chad Remesch <chad> |
| Component: | lvm | Assignee: | Stephen Tweedie <sct> |
| Status: | CLOSED DUPLICATE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | eg_bugzilla, jch, matt, menscher, mhedemark, olaf.meske, vaultdweller |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-08-31 13:44:29 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: | |||
Workaround #3 should be ignored since it didn't work for me when I went back to try it. It may be useful to use the 'remount,noload' options in conjuction with workaround #2 if that would force the journal to write to disk before creating the snapshot. I have experienced the same problem. Workarounds #1 and #2 allowed me to mount the snapshot; however, Workaround #3 did not. See my attachment in for a temp fix https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84278 don't kill me if it doesn't work for you. Option 2 worked for me (kernel 2.4.20-18.9, ext3) - did not try option 1 because it is not a real option for me. The patch from Matthew Kent seems to be already included in latest update kernel 2.4.20-18.9 but it does not work for me, failure is 100% reproducible. The question is: can the data in the snapshot be trusted...? This was fixed a long time ago by Sistina in their LVM VFS patch which, if I'm not mistaken, is in the mainline kernel source. Why RH continues to leave this code out is beyond speculation. Could this please be added to the next kernel RPM? Details about the patch can be found in the LVM howto: http://www.tldp.org/HOWTO/LVM-HOWTO/buildlvmpatch.html I see also that both RH9 and Severn are running an older version of LVM. Ok, I have found a workaround. I happen to be running 2.4.20-18.9, but I would assume this would work with the latest kernel source. In /usr/src/linux-2.4/drivers/md/lvm.c, uncomment the following line: #define LVM_VFS_ENHANCEMENT Recompile the kernel and you should be able to mount snapshots of mounted ext3 filesystems. Does anyone have any idea why this is commented out? |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Description of problem: Goal: create and mount a LVM ext3 filesystem snapshot while the parent filesystem is mounted read & write. Mounting a LVM ext3 filesystem snapshot fails with an error: mount: block device /dev/home_vg/snapshot is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/h_vg/snapshot, or too many mounted file systems A kernel patch (linux-2.4.20-VFS-lock.patch) exists in the LVM 1.0.7 source tar.gz that might fix the problem, but it didn't apply cleanly for me (thus I gave up on that option). Some temporary workarounds seem to exist for this problem: Workaround #1... 1. umount the live file system (umount /home). 2. create snapshot (lvcreate -l 100 -s -n snapshot /dev/h_vg/h_lv). 3. mount the snapshot (mount /dev/h_vg/snapshot /snapshot). 4. mount the original file system (mount /home). Workaround #2... 1. create a snapshot of a live filesystem. Example: lvcreate -l 100 -s -n snapshot /dev/h_vg/h_lv 2. mount the snapshot using the 'sb=' option. Example: mount -o ro,sb=131072 -t ext3 /dev/h_vg/snapshot /snapshot NOTE: 131072 is a valid backup superblock for my test fileystem. Workaround #3... 1. remount,noload live filesystem (mount -o remount,noload /home). 2. create snapshot (lvcreate -l 100 -s -n snapshot /dev/h_vg/h_lv). 3. mount snapshot (mount /dev/h_vg/snapshot /snapshot). 4. remount live filesystem (mount -o remount /home). I do not know if any of these workarounds are safe to use. Does anyone know if it is safe to assume the journal has been flushed when running the mount command in above workaround #2? Any chance a real fix will make its way in to an errata redhat kernel for 9? Finally, this is probably a duplicate of bug #84278, but everytime I try posting 'additional comments' to that bug I get the error: "You tried to change the component field from AfterStep-APPS to lvm, but only the owner or submitter of the bug, or a sufficiently empowered user, may change that field." Version-Release number of selected component (if applicable): stock redhat kernel 2.4.20-6 How reproducible: Always Steps to Reproduce: 1. Mount a live read/write LVM ext3 filesystem. 2. Create a snapshot of it. 3. Try and mount it. Actual Results: mount: block device /dev/home_vg/snapshot is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/home_vg/snapshot, or too many mounted file systems Expected Results: Mount should succeed. Additional info: