[linux-lvm] LVM and inactive snapshots.

[linux-lvm] LVM and inactive snapshots.

[Jay Weber]

Hi,

It seems both LVM 0.8 and 0.9 don't address snapshots running out of
reserved space very well.  From experience using it here's what I'm
seeing.

When a snapshot runs out of reserved space, lvm deactivates the snapshot
and cleans up it's allocation units it was using for it.  It still leaves
the snapshot volume device around as well and if the snapshot was actively
mounted, it remains mounted.  Keep in mind after the snapshot has gone
inactive, the dataset image it is portraying is NOT the same as it was
prior, viewing it in inactive state seems to show the exact same data that
the source volume contains, ie. it's a pointer back to source volume.

Given the above I'm curious as to how others view this behaviour.  I'm
thinking along the lines of:  If the snapshot goes inactive and it's
portrayal of the filesystem is no longer valid it should go away. Go away
meaning, if an inactive snapshot volume is currently mounted possibly we
should forcefully unmount it as well as cleaning up it's device node
entries and removing it as a block device.

Does that seem proper?

I suppose the ideal here is that you should never run out of reserved
space though, and if you were DEPENDING on that snapshot and you did run
out of reserved space, well, I assume you're just completely screwed in
that case. :)

Re: [linux-lvm] LVM and inactive snapshots.

[Jay Weber]

Along these lines, after I filled a snapshot I did the following:

	umount /snapshot
	umount /source
	vgchange -an
	rmmod lvm-mod
	insmod lvm-mod
	vgscan
	vgchange -ay
	lvdisplay /snapshot

And the snapshot showed that it was active and had 0% of it's reserved
space filled.  BUG?

On Wed, 13 Dec 2000, Jay Weber wrote:

> Hi,
> 
> It seems both LVM 0.8 and 0.9 don't address snapshots running out of
> reserved space very well.  From experience using it here's what I'm
> seeing.
> 
> When a snapshot runs out of reserved space, lvm deactivates the snapshot
> and cleans up it's allocation units it was using for it.  It still leaves
> the snapshot volume device around as well and if the snapshot was actively
> mounted, it remains mounted.  Keep in mind after the snapshot has gone
> inactive, the dataset image it is portraying is NOT the same as it was
> prior, viewing it in inactive state seems to show the exact same data that
> the source volume contains, ie. it's a pointer back to source volume.
> 
> Given the above I'm curious as to how others view this behaviour.  I'm
> thinking along the lines of:  If the snapshot goes inactive and it's
> portrayal of the filesystem is no longer valid it should go away. Go away
> meaning, if an inactive snapshot volume is currently mounted possibly we
> should forcefully unmount it as well as cleaning up it's device node
> entries and removing it as a block device.
> 
> Does that seem proper?
> 
> I suppose the ideal here is that you should never run out of reserved
> space though, and if you were DEPENDING on that snapshot and you did run
> out of reserved space, well, I assume you're just completely screwed in
> that case. :)
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> 

Re: [linux-lvm] LVM and inactive snapshots.

[Michael Marxmeier]

> Given the above I'm curious as to how others view this behaviour.  I'm
> thinking along the lines of:  If the snapshot goes inactive and it's
> portrayal of the filesystem is no longer valid it should go away. Go away
> meaning, if an inactive snapshot volume is currently mounted possibly we
> should forcefully unmount it as well as cleaning up it's device node
> entries and removing it as a block device.
> 
> Does that seem proper?

No. The kernel should not unmount because this may cause
confusion and possibly corruption of user mode information
(eg. /etc/mtab).

If a snapshot is dead the kernel could simply return an error
(EIO?) for any access to the snapshot (which no longer exists).
So the bahaviour would be well defined.


Michael

--
Michael Marxmeier           Marxmeier Software AG
E-Mail: mike@msede.com      Besenbruchstrasse 9
Phone : +49 202 2431440     42285 Wuppertal, Germany
Fax   : +49 202 2431420     http://www.msede.com/

Re: [linux-lvm] LVM and inactive snapshots.

[Jay Weber]

> No. The kernel should not unmount because this may cause
> confusion and possibly corruption of user mode information
> (eg. /etc/mtab).
> 
> If a snapshot is dead the kernel could simply return an error
> (EIO?) for any access to the snapshot (which no longer exists).
> So the bahaviour would be well defined.

Ah, yes, this does seem more reasonable and does address the issue of the
bits that are left lying about.

> 
> 
> Michael
> 
> --
> Michael Marxmeier           Marxmeier Software AG
> E-Mail: mike@msede.com      Besenbruchstrasse 9
> Phone : +49 202 2431440     42285 Wuppertal, Germany
> Fax   : +49 202 2431420     http://www.msede.com/
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> 

Re: [linux-lvm] LVM and inactive snapshots.

[Patrick Caulfield]

On Thu, Dec 14, 2000 at 03:10:05PM -0600, Jay Weber wrote:
> > No. The kernel should not unmount because this may cause
> > confusion and possibly corruption of user mode information
> > (eg. /etc/mtab).
> > 
> > If a snapshot is dead the kernel could simply return an error
> > (EIO?) for any access to the snapshot (which no longer exists).
> > So the bahaviour would be well defined.
> 
> Ah, yes, this does seem more reasonable and does address the issue of the
> bits that are left lying about.

THis patch should do that. It doesn't address the problem of remounting the
inactive snapshot though.

Patrick


--- drivers/md/lvm.c~   Thu Dec 14 14:31:21 2000
+++ drivers/md/lvm.c    Fri Dec 15 09:46:15 2000
@@ -1678,6 +1678,8 @@
                        down(&lv->lv_snapshot_sem);
                        if (lv->lv_block_exception != NULL)
                                lvm_snapshot_remap_block(&rdev_tmp, &rsector_tmp, pe_start, lv);
+                       else
+                           ret = 1;
                        up(&lv->lv_snapshot_sem);
                }
        }