[dm-devel] Snapshot/VFS-lock tests

[Kevin Corry]

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 at us.ibm.com
http://evms.sourceforge.net/