Joe, I've finished running some tests to see how each filesystem reacts to taking snapshots with and without the VFS-lock patch. Here was my basic procedure for each test: 1) Create a volume. 2) mkfs with the desired filesystem. 3) Mount the volume. 4) Start copying a kernel source tree to the volume. 5) While mounted and copying, create a snapshot of the volume. - Both writeable and read-only snapshots were tested. 6) Mount the snapshot. 7) Check mount output and syslog for any filesystem errors or warnings. These tests were run with the patches from your 2.4.21-dm-2 release, including the patch to move the VFS-locking to dm.c, the new experimental VFS-lock patch, and the origin-ctr patch I submitted. Here are the results: Note: all read-only snapshot tests generated the following message when mounting the snapshot: mount: block device /dev/evms/snap1 is write-protected, mounting read-only XFS notes: I used the latest XFS snapshot for 2.4.21, dated July 6. XFS requires the "-o nouuid" option in order to mount a filesystem with the same UUID twice. ext2: writeable snapshot: with VFS-lock: EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended without VFS-lock: EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended read-only snapshot: with VFS-lock: (no extra messages) without VFS-lock: (no extra messages) ext3: writeable snapshot: with VFS-lock: kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on device-mapper(254,17), internal journal EXT3-fs: mounted filesystem with ordered data mode. without VFS-lock: kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on device-mapper(254,17), internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. read-only snapshot: with VFS-lock: Can't write to read-only device fe:11 kjournald starting. Commit interval 5 seconds Can't write to read-only device fe:11 EXT3-fs: mounted filesystem with ordered data mode. without VFS-lock: mount: wrong fs type, bad option, bad superblock on /dev/evms/snap1, or too many mounted file systems EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access unavailable, cannot proceed. Reiserfs: writeable snapshot: with VFS-lock: reiserfs: checking transaction log (device fe:11) ... Using r5 hash to sort names ReiserFS version 3.6.25 without VFS-lock: eiserfs: checking transaction log (device fe:11) ... reiserfs: replayed 4 transactions in 17 seconds Using r5 hash to sort names ReiserFS version 3.6.25 read-only snapshot: with VFS-lock: reiserfs: checking transaction log (device fe:11) ... Using r5 hash to sort names ReiserFS version 3.6.25 without VFS-lock: mount: wrong fs type, bad option, bad superblock on /dev/evms/snap1, or too many mounted file systems reiserfs: checking transaction log (device fe:11) ... clm-2076: device is readonly, unable to replay log Replay Failure, unable to mount reiserfs_read_super: unable to initialize journal space JFS: writeable snapshot: with VFS-lock: mount: wrong fs type, bad option, bad superblock on /dev/evms/snap1, or too many mounted file systems without VFS-lock: mount: wrong fs type, bad option, bad superblock on /dev/evms/snap1, or too many mounted file systems read-only snapshot: with VFS-lock: (no extra messages) without VFS-lock: (no extra messages) XFS; writeable snapshot: with VFS-lock: mount: wrong fs type, bad option, bad superblock on /dev/evms/snap1, or too many mounted file systems XFS mounting filesystem device-mapper(254,17) Starting XFS recovery on filesystem: device-mapper(254,17) (dev: 254/17) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed without VFS-lock: mount: wrong fs type, bad option, bad superblock on /dev/evms/snap1, or too many mounted file systems XFS mounting filesystem device-mapper(254,17) Starting XFS recovery on filesystem: device-mapper(254,17) (dev: 254/17) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed read-only snapshot: with VFS-lock: XFS mounting filesystem device-mapper(254,17) Ending clean XFS mount for filesystem: device-mapper(254,17) without VFS-lock: mount: wrong fs type, bad option, bad superblock on /dev/evms/snap1, or too many mounted file systems XFS mounting filesystem device-mapper(254,17) XFS: recovery required required on read-only device. XFS: write access unavailable, cannot proceed. XFS: log mount/recovery failed XFS: log mount failed So, in summary: Ext2 doesn't seem to care one way or the other. It will always complain about needing an fsck on a writeable snapshot, and never complains about read-only snapshots. This is what we'd expect from a non-journalled filesystem. Ext3 will work either way on writeable snapshots, but has to replay its journal without the VFS-lock patch. It will *not* work on read-only snapshots without the VFS-lock patch, since it can't replay its journal. Reiser behaves just like ext3. JFS is just weird. It doesn't like writeable snapshots, period (at least, not while the origin is in use). It also doesn't mind read-only snapshots, even without the VFS-lock patch, which goes against what we'd expect for journalled filesystems. I'm going to have to talk to Shaggy about this. XFS just doesn't seem to like snapshots very much. I remember somebody mentioning once they had to run something like "xfs_freeze" in order to take snapshots of XFS. I will look into this and perhaps run the XFS tests again. In my opinion, ext3 and reiser are exhibiting the "correct" behavior. I'll look into JFS and XFS some more today and let you know if I find out anything interesting. -- Kevin Corry kevcorry@xxxxxxxxxx http://evms.sourceforge.net/