Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 88115

Summary: error mounting lvm ext3 snapshot
Product: [Retired] Red Hat Linux Reporter: Chad Remesch <chad>
Component: lvmAssignee: Stephen Tweedie <sct>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: 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:

Description Chad Remesch 2003-04-06 01:26:21 UTC
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:

Comment 1 Chad Remesch 2003-04-06 01:40:58 UTC
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.

Comment 2 Mark Roberts 2003-04-06 01:43:14 UTC
I have experienced the same problem. Workarounds #1 and #2 allowed me to mount
the snapshot; however, Workaround #3 did not.

Comment 3 Matthew Kent 2003-05-05 21:33:27 UTC
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.

Comment 4 Karl Kiniger 2003-06-23 13:20:17 UTC
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...? 

Comment 5 Magnus Hedemark 2003-07-24 19:19:58 UTC
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?

Comment 6 Magnus Hedemark 2003-07-25 20:25:09 UTC
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.

Comment 7 Mark Roberts 2003-10-13 04:06:39 UTC
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?

Comment 8 Stephen Tweedie 2003-10-23 17:32:02 UTC

*** This bug has been marked as a duplicate of 97843 ***