How do you mount a snapshot?

From what I've read it looks like the oopses on mounting snapshots have been fixed since I last tried playing with them so I am at it again. I have a freshly installed RH7.0 system with the 2.4.0-test10 kernel patched for LVM 0.9 and reiserfs 3.6.22. I can successfully create a snapshot with:

lvcreate -s -L16 -nsnapshot /dev/vg-sdb1/lv-sdb1

but when I try to mount it:

[root@computer /usr2]# mount -t reiserfs /dev/vg-sdb1/snapshot /snap/
mount: block device /dev/vg-sdb1/snapshot is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/vg-sdb1/snapshot,
or too many mounted file systems

Without specifying the filesystem type I get:

[root@computer /usr2]# mount /dev/vg-sdb1/snapshot /snap/
mount: /dev/vg-sdb1/snapshot has wrong major or minor number

I was using mount mount-2.10m but I downloaded the fileutils and compiled and tried mount-2.10r and I get the same results.

What else do I need to do in order to get a snapshot mounted?

Tracy Reed      http://www.ultraviolet.org

Unless they have changed it (possible), reiserfs does not support ro hardware for mounting unless the filesystem was unmounted cleanly. The reason is that to make the FS consistant the journal has to be replayed which necessarily _writes_ to the device. This cannot work on an ro device.

-dg

David Gould                                                 [email protected]
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
"As I've gained more experience with Perl it strikes me that it
 resembles Lisp in many ways, albeit Lisp as channeled by an awk
 script on acid."  -- Tim Moore <[email protected]>,
                      on comp.lang.lisp

We didn't change that ;-) But, the message would look different. In this case, it did not find a reiserfs filesystem at all, or perhaps the reiserfs module wasn't loaded...

-chris

Hmm....

So...can I or can I not use snapshots with reiserfs? The snapshot was taken of a currently mounted and functioning (reiserfs module loaded...compiled into the kernel, actually) so if I did the snapshot correctly there should be a filesystem there. I'm going to wipe it out (nothing on it but some test files) and try again with ext2 and see what happens.

This should work, shouldn't it?

Tracy Reed      http://www.ultraviolet.org

It should work with ext2.

You can make reiserfs snapshots, but you also need to apply the linux-2.4.0-test10-VFS-lock.patch that comes with the LVM 0.9 code. This adds the hooks LVM needs to ask reiserfs to make the FS consistent before creating the snapshot.

And, you need to edit linux/drivers/block/lvm.c, and uncomment the LVM_VFS_ENHANCEMENT #define. This enables the LVM code that uses the hooks.

-chris

Ah-ha! It works. Thank you!

Tracy Reed      http://www.ultraviolet.org

Really? I wonder. Maybe right after a sync before anything gets dirtied, but otherwise, how could the disk image be consistantly, er, consistant? And would not e2fsck have the same issues about writing?

Or did I just wake up pessimistic today?

-dg

David Gould                                                 [email protected]
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
"As I've gained more experience with Perl it strikes me that it
 resembles Lisp in many ways, albeit Lisp as channeled by an awk
 script on acid."  -- Tim Moore <[email protected]>,
                      on comp.lang.lisp

[ snapshots ]

The reason it will not work on reiserfs without the extra API is that on reiserfs, sync == commit to log, not commit to disk. So, there is no way over the command line (or in the kernel) to ask the FS to sync to disk, even when there is no traffic at all on the FS.

With ext2, if nothing is going on, you can type sync and have all the buffers on disk. It is at least possible ;-) It would be better if ext2 could provide the write suspension hooks as well, but I'm guessing that will be done in ext3 first (where the journal already does most of the work).

In my mind, the people that need snapshots the most are the database programs, where disk traffic can be carefully controlled. So the current ext2 method is still useful.

-chris

Hello, this is for sure a newbie question, but i havent found any docs about it.
I am running 2.2.16 + LVM 0.8 (a Suse precompiled kernel) and want to upgrade to 0.9.
If i just patch 2.2.17 vanilla + LFS + LVM + RAWIO, compile, install and reboot, using the 0.9 lvm tools, it doesnt work.
What commands should i use?
vgscan doesnt work...

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Programmer/Networker [|] Magnus Naeslund
PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Ok, so we are agreeing, it does not work on ext2 either unless you sync and do not write between the sync and the snapshot. Doable, but not exactly "safe".

-dg

David Gould                                                 [email protected]
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
"As I've gained more experience with Perl it strikes me that it
 resembles Lisp in many ways, albeit Lisp as channeled by an awk
 script on acid."  -- Tim Moore <[email protected]>,
                      on comp.lang.lisp

exactly

hmm, I think it works for ext2 because you can always mount an ext2 filesystem even if it's in an inconsistent state. This is what happens everytime when your machine panics and you need to fsck your disks during the reboot, the root filesystem is mounted read-only... It's my understanding, that reiserfs will always "fsck" (replay it's log) on mount and that's why it won't mount read-only when the filesystem is not in a consistent state. What I don't know is if it would be possible to make reiserfs not care about the inconsistencies (i.e. not replay the log) when it mounts read-only?

An atomic sync-snapshot is of course the (implemented) solution, but it would be nice if it would also work without that...

christian

LVM 0.9 kernel 2.2.17.

What's up?
I'll disable "show lvm in proc" stuff, because the EIP:
lvm_do_create_proc_entry_of_pv
look a little suspect, man...

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Programmer/Networker [|] Magnus Naeslund
PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Dec 11 04:59:28 gprods1 kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000002c
Dec 11 04:59:28 gprods1 kernel: current->tss.cr3 = 1f7e1000, %cr3 = 1f7e1000
Dec 11 04:59:28 gprods1 kernel: *pde = 00000000
Dec 11 04:59:28 gprods1 kernel: Oops: 0000
Dec 11 04:59:28 gprods1 kernel: CPU:    0
Dec 11 04:59:28 gprods1 kernel: EIP:
0010:[lvm_do_create_proc_entry_of_pv+23/100]
Dec 11 04:59:28 gprods1 kernel: EFLAGS: 00010246
Dec 11 04:59:28 gprods1 kernel: eax: 00002f2f   ebx: 00000000   ecx:
de85d400   edx: 00000000
Dec 11 04:59:28 gprods1 kernel: esi: 0000002c   edi: 08071ff8   ebp:
0000002c   esp: ddd97d94
Dec 11 04:59:28 gprods1 kernel: ds: 0018   es: 0018   ss: 0018
Dec 11 04:59:28 gprods1 kernel: Process vgextend (pid: 595, process nr: 21,
stackpage=ddd97000)
Dec 11 04:59:28 gprods1 kernel: Stack: 08071ff8 dffdc000 c01b3fa2 dffdc000
00000000 08071ff8 dffdc000 00000002
Dec 11 04:59:28 gprods1 kernel:        4004fe03 08071ff8 c01b19bb dffdc000
08071ff8 df1d98e0 ffffffe7 08071ff8
Dec 11 04:59:28 gprods1 kernel:        4004fe03 00000000 08071ff8 c01ee5e9
00000001 00000000 00000000 00000000
Dec 11 04:59:28 gprods1 kernel: Call Trace: [lvm_do_vg_extend+78/140]
[lvm_chr_ioctl+671/1696] [number+377/704] [min_sb_len.516+27276/27788]
[lf+47/92] [vsprintf+892/952] [vsprintf+892/952]
Dec 11 04:59:28 gprods1 kernel:        [sprintf+20/5456]
[head_vals.693+682/15960] [sprintf+20/5456] [head_vals.693+683/15960]
[get_partition_list+114/152] [head_vals.693+666/15960]
[do_follow_link+120/132] [lookup_dentry+351/488]
Dec 11 04:59:28 gprods1 kernel:        [get_chrfops+30/36]
[tvecs+10300/13824] [chrdev_open+63/76] [filp_open+256/328]
[sys_ioctl+441/484] [free_pages+41/44] [sys_open+130/172]
[system_call+52/56]
Dec 11 04:59:28 gprods1 kernel: Code: ac 38 e0 75 03 8d 56 ff 84 c0 75 f4 85
d2 75 05 89 ea eb 02
Dec 11 05:02:45 gprods1 kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000002c
Dec 11 05:02:45 gprods1 kernel: current->tss.cr3 = 1dde8000, %cr3 = 1dde8000
Dec 11 05:02:45 gprods1 kernel: *pde = 00000000
Dec 11 05:02:45 gprods1 kernel: Oops: 0000
Dec 11 05:02:45 gprods1 kernel: CPU:    1
Dec 11 05:02:45 gprods1 kernel: EIP:
0010:[lvm_do_create_proc_entry_of_pv+23/100]
Dec 11 05:02:45 gprods1 kernel: EFLAGS: 00010246
Dec 11 05:02:45 gprods1 kernel: eax: 00002f2f   ebx: 00000000   ecx:
de85d400   edx: 00000000
Dec 11 05:02:45 gprods1 kernel: esi: 0000002c   edi: 08071ff8   ebp:
0000002c   esp: ddd97d94
Dec 11 05:02:45 gprods1 kernel: ds: 0018   es: 0018   ss: 0018
Dec 11 05:02:45 gprods1 kernel: Process vgextend (pid: 621, process nr: 21,
stackpage=ddd97000)
Dec 11 05:02:45 gprods1 kernel: Stack: 08071ff8 dffdc000 c01b3fa2 dffdc000
00000000 08071ff8 dffdc000 00000002
Dec 11 05:02:45 gprods1 kernel:        4004fe03 08071ff8 c01b19bb dffdc000
08071ff8 ddf806c0 ffffffe7 08071ff8
Dec 11 05:02:45 gprods1 kernel:        4004fe03 00000000 08071ff8 c01ee5e9
00000001 00000000 00000000 00000000
Dec 11 05:02:45 gprods1 kernel: Call Trace: [lvm_do_vg_extend+78/140]
[lvm_chr_ioctl+671/1696] [number+377/704] [min_sb_len.516+27276/27788]
[lf+47/92] [vsprintf+892/952] [vsprintf+892/952]
Dec 11 05:02:45 gprods1 kernel:        [sprintf+20/5456]
[head_vals.693+682/15960] [sprintf+20/5456] [head_vals.693+683/15960]
[get_partition_list+114/152] [head_vals.693+666/15960]
[do_follow_link+120/132] [lookup_dentry+351/488]
Dec 11 05:02:45 gprods1 kernel:        [get_chrfops+30/36]
[tvecs+10300/13824] [chrdev_open+63/76] [filp_open+256/328]
[sys_ioctl+441/484] [free_pages+41/44] [sys_open+130/172]
[system_call+52/56]
Dec 11 05:02:45 gprods1 kernel: Code: ac 38 e0 75 03 8d 56 ff 84 c0 75 f4 85
d2 75 05 89 ea eb 02
Dec 11 05:02:48 gprods1 kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000002c
Dec 11 05:02:48 gprods1 kernel: current->tss.cr3 = 1dde8000, %cr3 = 1dde8000
Dec 11 05:02:48 gprods1 kernel: *pde = 00000000
Dec 11 05:02:48 gprods1 kernel: Oops: 0000
Dec 11 05:02:48 gprods1 kernel: CPU:    0
Dec 11 05:02:48 gprods1 kernel: EIP:
0010:[lvm_do_create_proc_entry_of_pv+23/100]
Dec 11 05:02:48 gprods1 kernel: EFLAGS: 00010246
Dec 11 05:02:48 gprods1 kernel: eax: 00002f2f   ebx: 00000000   ecx:
de85d200   edx: 00000000
Dec 11 05:02:48 gprods1 kernel: esi: 0000002c   edi: 08071ff8   ebp:
0000002c   esp: ddd97d94
Dec 11 05:02:48 gprods1 kernel: ds: 0018   es: 0018   ss: 0018
Dec 11 05:02:48 gprods1 kernel: Process vgextend (pid: 622, process nr: 21,
stackpage=ddd97000)
Dec 11 05:02:48 gprods1 kernel: Stack: 08071ff8 dffdc000 c01b3fa2 dffdc000
00000000 08071ff8 dffdc000 00000003
Dec 11 05:02:48 gprods1 kernel:        4004fe03 08071ff8 c01b19bb dffdc000
08071ff8 df1d9560 ffffffe7 08071ff8
Dec 11 05:02:48 gprods1 kernel:        4004fe03 00000000 08071ff8 c01ee5e9
00000001 00000000 00000000 00000000
Dec 11 05:02:48 gprods1 kernel: Call Trace: [lvm_do_vg_extend+78/140]
[lvm_chr_ioctl+671/1696] [number+377/704] [min_sb_len.516+27276/27788]
[lf+47/92] [vsprintf+892/952] [vsprintf+892/952]
Dec 11 05:02:48 gprods1 kernel:        [sprintf+20/5456]
[head_vals.693+682/15960] [sprintf+20/5456] [head_vals.693+683/15960]
[get_partition_list+114/152] [head_vals.693+666/15960]
[do_follow_link+120/132] [lookup_dentry+351/488]
Dec 11 05:02:48 gprods1 kernel:        [get_chrfops+30/36]
[tvecs+10300/13824] [chrdev_open+63/76] [filp_open+256/328]
[sys_ioctl+441/484] [free_pages+41/44] [sys_open+130/172]
[system_call+52/56]
Dec 11 05:02:48 gprods1 kernel: Code: ac 38 e0 75 03 8d 56 ff 84 c0 75 f4 85
d2 75 05 89 ea eb 02
Dec 11 05:02:53 gprods1 kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000002c
Dec 11 05:02:53 gprods1 kernel: current->tss.cr3 = 1dde8000, %cr3 = 1dde8000
Dec 11 05:02:53 gprods1 kernel: *pde = 00000000
Dec 11 05:02:53 gprods1 kernel: Oops: 0000
Dec 11 05:02:53 gprods1 kernel: CPU:    0
Dec 11 05:02:53 gprods1 kernel: EIP:
0010:[lvm_do_create_proc_entry_of_pv+23/100]
Dec 11 05:02:53 gprods1 kernel: EFLAGS: 00010246
Dec 11 05:02:53 gprods1 kernel: eax: 00002f2f   ebx: 00000000   ecx:
de85d600   edx: 00000000
Dec 11 05:02:53 gprods1 kernel: esi: 0000002c   edi: 08071ff8   ebp:
0000002c   esp: ddd97d94
Dec 11 05:02:53 gprods1 kernel: ds: 0018   es: 0018   ss: 0018
Dec 11 05:02:53 gprods1 kernel: Process vgextend (pid: 624, process nr: 21,
stackpage=ddd97000)
Dec 11 05:02:53 gprods1 kernel: Stack: 08071ff8 dffdc000 c01b3fa2 dffdc000
00000000 08071ff8 dffdc000 00000004
Dec 11 05:02:53 gprods1 kernel:        4004fe03 08071ff8 c01b19bb dffdc000
08071ff8 df1d96e0 ffffffe7 08071ff8
Dec 11 05:02:53 gprods1 kernel:        4004fe03 00000000 08071ff8 c01ee5e9
00000001 00000000 00000000 00000000
Dec 11 05:02:53 gprods1 kernel: Call Trace: [lvm_do_vg_extend+78/140]
[lvm_chr_ioctl+671/1696] [number+377/704] [min_sb_len.516+27276/27788]
[vsprintf+892/952] [vsprintf+892/952] [sprintf+20/5456]
Dec 11 05:02:53 gprods1 kernel:        [head_vals.693+682/15960]
[sprintf+20/5456] [head_vals.693+683/15960] [get_partition_list+114/152]
[head_vals.693+666/15960] [do_follow_link+120/132] [lookup_dentry+351/488]
[get_chrfops+30/36]
Dec 11 05:02:53 gprods1 kernel:        [tvecs+10300/13824]
[chrdev_open+63/76] [filp_open+256/328] [sys_ioctl+441/484]
[free_pages+41/44] [sys_open+130/172] [system_call+52/56]
Dec 11 05:02:53 gprods1 kernel: Code: ac 38 e0 75 03 8d 56 ff 84 c0 75 f4 85
d2 75 05 89 ea eb 02
Dec 11 05:03:21 gprods1 kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000002c
Dec 11 05:03:21 gprods1 kernel: current->tss.cr3 = 1dde8000, %cr3 = 1dde8000
Dec 11 05:03:21 gprods1 kernel: *pde = 00000000
Dec 11 05:03:21 gprods1 kernel: Oops: 0000
Dec 11 05:03:21 gprods1 kernel: CPU:    0
Dec 11 05:03:21 gprods1 kernel: EIP:
0010:[lvm_do_create_proc_entry_of_pv+23/100]
Dec 11 05:03:21 gprods1 kernel: EFLAGS: 00010246
Dec 11 05:03:21 gprods1 kernel: eax: 00002f2f   ebx: 00000000   ecx:
de85d000   edx: 00000000
Dec 11 05:03:21 gprods1 kernel: esi: 0000002c   edi: 08071d80   ebp:
0000002c   esp: ddd97d94
Dec 11 05:03:21 gprods1 kernel: ds: 0018   es: 0018   ss: 0018
Dec 11 05:03:21 gprods1 kernel: Process vgextend (pid: 628, process nr: 21,
stackpage=ddd97000)
Dec 11 05:03:21 gprods1 kernel: Stack: 08071d80 dffdc000 c01b3fa2 dffdc000
00000000 08071d80 dffdc000 00000005
Dec 11 05:03:21 gprods1 kernel:        4004fe03 08071d80 c01b19bb dffdc000
08071d80 df1d9760 ffffffe7 08071d80
Dec 11 05:03:21 gprods1 kernel:        4004fe03 00000000 08071d80 c01ee5e9
00000001 00000000 00000000 00000000
Dec 11 05:03:21 gprods1 kernel: Call Trace: [lvm_do_vg_extend+78/140]
[lvm_chr_ioctl+671/1696] [number+377/704] [min_sb_len.516+27276/27788]
[lf+47/92] [vsprintf+892/952] [vsprintf+892/952]
Dec 11 05:03:21 gprods1 kernel:        [sprintf+20/5456]
[head_vals.693+682/15960] [sprintf+20/5456] [head_vals.693+683/15960]
[get_partition_list+114/152] [head_vals.693+666/15960]
[do_follow_link+120/132] [lookup_dentry+351/488]
Dec 11 05:03:21 gprods1 kernel:        [get_chrfops+30/36]
[tvecs+10300/13824] [chrdev_open+63/76] [filp_open+256/328]
[sys_ioctl+441/484] [free_pages+41/44] [sys_open+130/172]
[system_call+52/56]
Dec 11 05:03:21 gprods1 kernel: Code: ac 38 e0 75 03 8d 56 ff 84 c0 75 f4 85
d2 75 05 89 ea eb 02
Dec 11 05:05:14 gprods1 kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000002c
Dec 11 05:05:14 gprods1 kernel: current->tss.cr3 = 1dde8000, %cr3 = 1dde8000
Dec 11 05:05:14 gprods1 kernel: *pde = 00000000
Dec 11 05:05:14 gprods1 kernel: Oops: 0000
Dec 11 05:05:14 gprods1 kernel: CPU:    0
Dec 11 05:05:14 gprods1 kernel: EIP:
0010:[lvm_do_create_proc_entry_of_pv+23/100]
Dec 11 05:05:14 gprods1 kernel: EFLAGS: 00010246
Dec 11 05:05:14 gprods1 kernel: eax: 00002f2f   ebx: 00000000   ecx:
ddbc7e00   edx: 00000000
Dec 11 05:05:14 gprods1 kernel: esi: 0000002c   edi: 08071ff8   ebp:
0000002c   esp: ddd97d94
Dec 11 05:05:14 gprods1 kernel: ds: 0018   es: 0018   ss: 0018
Dec 11 05:05:14 gprods1 kernel: Process vgextend (pid: 638, process nr: 21,
stackpage=ddd97000)
Dec 11 05:05:14 gprods1 kernel: Stack: 08071ff8 dffdc000 c01b3fa2 dffdc000
00000000 08071ff8 dffdc000 00000006
Dec 11 05:05:14 gprods1 kernel:        4004fe03 08071ff8 c01b19bb dffdc000
08071ff8 df1d97e0 ffffffe7 08071ff8
Dec 11 05:05:14 gprods1 kernel:        4004fe03 00000000 08071ff8 c01ee5e9
00000001 00000000 00000000 00000000
Dec 11 05:05:14 gprods1 kernel: Call Trace: [lvm_do_vg_extend+78/140]
[lvm_chr_ioctl+671/1696] [number+377/704] [min_sb_len.516+27276/27788]
[lf+47/92] [vsprintf+892/952] [vsprintf+892/952]
Dec 11 05:05:14 gprods1 kernel:        [sprintf+20/5456]
[head_vals.693+682/15960] [sprintf+20/5456] [head_vals.693+683/15960]
[get_partition_list+114/152] [head_vals.693+666/15960]
[do_follow_link+120/132] [lookup_dentry+351/488]
Dec 11 05:05:14 gprods1 kernel:        [get_chrfops+30/36]
[tvecs+10300/13824] [chrdev_open+63/76] [filp_open+256/328]
[sys_ioctl+441/484] [free_pages+41/44] [sys_open+130/172]
[system_call+52/56]
Dec 11 05:05:14 gprods1 kernel: Code: ac 38 e0 75 03 8d 56 ff 84 c0 75 f4 85

d2 75 05 89 ea eb 02

Ok, but then you have an inconsistant filesystem. Which is not exactly what I think of as "works" or "safe". My point was that snapshots are great, but don't make the problem of consistancy magically disappear.

-dg

David Gould                                                 [email protected]
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
"As I've gained more experience with Perl it strikes me that it
 resembles Lisp in many ways, albeit Lisp as channeled by an awk
 script on acid."  -- Tim Moore <[email protected]>,
                      on comp.lang.lisp

Yes. With ext2, the admin can take steps to make his FS consistent during the snapshot. It would be a painful manual process, but it is at least possible.

It would not be useful for snapshots to allow reiserfs disks to be mounted without a journal replay though. An inconsistent ext2 FS might have a few directories screwed up, or a rename in progress, or some bad bitmaps (or much worse, but we are pretending things are normal here). But, most of the time it will be mostly valid.

reiserfs just has one btree for everything, so if the snapshot comes in the middle of a given operation, it affects the btree for the whole FS. This means an inconsistent reiserfs disk has a much higher chance of having serious problems, almost regardless of the type of operation that was going on. So, the snapshot API does two things. It waits for all transaction operations to finish, and then it blocks new ones until the snapshot is setup.

Christian, just let me know if that doesn't answer your question.

-chris

Actually, the LVM snapshot code does an fsync_dev() call right before the snapshot is created, so the window in which the filesystem can become inconsistent is very small. For ext2 this is relatively safe, because fsync_dev() will flush everything to disk. For ext3 and reiserfs, the fsync_dev() isn't enough because it may only flush the data to the journal, and these filesystems will (currently) refuse to mount with a dirty journal on a read-only device.

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert