Red Hat Bugzilla – Bug 201751
lvcreate doesn't lockfs the origin filesystem when creating the first snapshot
Last modified: 2008-05-01 11:39:21 EDT
Description of problem:
lvcreate doesn't lockfs the origin filesystem when creating the first snapshot.
This leads to unusable snapshots because the filesystem isn't synced before
creating the snapshot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create LV test on VG test with ext3 filesystem
2. lvcreate -s -L 320M -n snap1 -p r test/test
3. mount -r /dev/test/snap1 /mnt
s390vm01:~ # mount -r /dev/test/snap1 /tmp/m1
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access unavailable, cannot proceed.
mount: wrong fs type, bad option, bad superblock on /dev/test/snap1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
The problem is in lib/activate/dev_manager.c:
if (!lv_is_origin(lv) && !lv_is_cow(lv))
When creating the first snapshot of a LV lv_is_origin() is still false because
we suspend the LV before creating the snapshot. Therefore the original LV is
suspended without lockfs.
Test set should include every command that does a suspend:
lvchange -ay (of all object types), lvcreate first snapshot, lvcreate second
snapshot of same device, lvremove second snapshot, lvchange --refresh, pvmove,
vgreduce --removemissing, lvresize, lvrename, lvconvert
lvm2-2.02.17-1.fc6 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Verified fixed in lvm2-2.02.19-1.el4.
[root@link-08 ~]# lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
origin vg owi-a- 600.00M
snap1 vg sri-a- 320.00M origin 0.00
[root@link-08 ~]# mount -r /dev/vg/snap1 /mnt/snap
Jan 24 09:48:54 link-08 kernel: kjournald starting. Commit interval 5 seconds
Jan 24 09:48:54 link-08 kernel: EXT3-fs: mounted filesystem with ordered data mode.
I also ran some of the other commands mentioned in comment #1