From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030120 Description of problem: after creating an lvm snapshot of a reiserfs lv, I tried to mount it and received an error. I believe there is a kernel patch which fixes this problem. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.create an lv and mkfs -t reseiserfs 2. lvcreate --size 100M --snapshot --name any /dev/vg/reiservol 3. mount -o ro /dev/vg/any /mount Actual Results: mount: block device /dev/test_vg/mail is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/test_vg/mail, or too many mounted file systems Expected Results: successful ro mount Additional info: I believe the problem is in linux/drivers/md/lvm.c There is a patch to orginal 2.4.20
Created attachment 91505 [details] Bring VFSlock patch up to 2.4.20 Cross between the vfslock patch in Sistina's cvs tree for vanilla 2.4.20 kernels and redhats old linux-2.4.18-lvm-VFSlock.patch. Just install the kernel-2.4.20-9.src.rpm, put the patch into SOURCES, and edit the spec file to use the new version :)
New kernel patch fixed problem.
Why hasn't this patch been added to the latest kernel release. There have been two kernel updates since this bug was fixed with the new patch yet the old patch is still being distributed.
*** Bug 88977 has been marked as a duplicate of this bug. ***
Created attachment 92568 [details] Patch so LVM flushes FSes when creating snapshots This is a patch against kernel-2.4.20-18.9 that allows ext3 (and presumably reiserfs and any other FS) to be flushed when creating LVM snapshots, so the snapshot is "clean" and can be mounted. All the supporting code is already there; this just uncomments the necessary calls from the LVM code.
This doesn't seem specific to reiser, it's appearing w/ ext3 file systems as well.
I never had a problem with ext3 or JFS mounting LVM snapshots. The only problem I had was with reiserfs. The kernel patch fixes the problem for me but has not yet made it into the distribution kernel for some reason. I have had to make custom kernel for two releases since the first working test patch was posted on 2003-05-05. I have not tested the 2003-06-23 patch. Harris
I was unable to mount an ext3 snapshot with the latest kernel until I applied the attached patch and rebuilt the kernel.
I also had problems with ext3 snapshots that were solved by applying the second patch listed. Actually -- I varied the patch slightly. The patch calls both fsync_dev(org->lv_dev); and fsync_dev_lockfs(org->lv_dev); which seems pointless, so I just used #ifdef/else/endif to call just the latter function. I'm surprised that this patch hasn't made its way in to the distributed kernel -- I would've thought that there were quite a lot of people who use snapshots to make reliable backups.
Yes, I'm very surprised too. No Red Hat person has even commented on this bug. Strange...
*sigh* another kernel update, another kernel that refuses to mount snapshots. Whats even more fun, taroon kernel seems to be effected by this as well, trying taroon kernel on a RHL9 system. Will do a full taroon install to verify when time permits. Why oh why can't we get this fixed?
Could the original bug reporter (that's you, Harris) please increase the priority of this bug so someone at RH will take notice? Not having the ability to perform a consistent tape backup is a pretty serious problem.
I just installed a 2.4.20-20.9 with the VFSlock patch and it no longer fixes the problem. I can't mount snapshots with this kernel.
*** This bug has been marked as a duplicate of 97843 ***