Re: DM_snapshot_cow filesystem (dmsetup create snapshot)

[Douglas McClendon <dmc.lists@filteredperception.org>]

On 12/01/2011 08:12 AM, Alasdair G Kergon wrote:
> On Wed, Nov 30, 2011 at 05:34:25PM -0600, Douglas McClendon wrote:
>> So wouldn't it be much better as far as the user is concerned if, the
>> instant a snapshot reached capacity, it fell over into a read-only state
>> (instead of being marked invalid?), such that further corruption beyond
>
> That would mean your *origin* device becoming read-only as well.

I apologize in that I know I may be getting some terminology confused, 
as devicemapper snapshots are used for many scenarios.  The fedora 
livecd/usb is perhaps only a subset of wider problem-constraints that 
I'm not keeping in mind.  That disclaimer said, in this particular 
situation, using the terminology I use in my own head, the base device 
here is a read-only ext3/4 filesystem image, necessarily read only 
because it is living on a squashfs filesystem, that may be on a 
read-only physical device like cdrom, or read-write (liveusb).

The overlay device in this situation is a read-write tmpfile in tmpfs, 
looped to be available as the dm-snapshot 'snapshot/overlay device'.

The resulting used device is then a read-write device used as a 
read-write ext3/4 filesystem for the rootfs.

When the snapshot fills up, keeping the snapshot device read-write would 
seem to serve no useful purpose.  And the 'base' device was read-only to 
begin with.

The real issue seems to be that the meaningfulness and usefulness of the 
overlay device seems to go from 'meaningful' to 'invalid/meaningless' 
the instant it fills up.  For no beneficial reason I can see (again 
maybe it complicates other dm-snapshot use-case scenarios that I'm not 
considering).


>
> It's been discussed before.  Nobody has been motivated to write the code,
> as there's no need for it on a properly-managed system.
>
> If you care enough about your snapshot contents, then surely you
> would be monitoring it to make sure it doesn't fill up - and if you're
> going to run out of space and can't expand, you would shut down your system
> yourself in a *controlled* way *before* running out of space!

In a typical livecd scenario, the amount of space in the snapshot can be 
very limited (say, half of ram).

In such a scenario, if the first thing I do is 'yum install lftp' I 
might be golden because that only takes a few MB.  If the next thing I 
do however is 'yum install emacs' or something else that brings in a ton 
of dependencies, that single command can exhaust the snapshot.

Are you suggesting some polling(or event driven?) method for the system 
to try to shutdown cleanly in the middle of that yum install?

I admit that would indeed solve the present use case of keeping the 
overlay device functionally usable.  In fact, going with a brutal 
virtual-plug-pulling halt triggered by snapshot full would be fine. 
Though I'd rather at that instant have the system go read-write-rootfs 
so that I can still poke around somewhat, rather than the screen go black.

But I really see no downside to keeping it usable without that 
pro-active infrastructure, by instead just making sure that when it 
fills up, it remains a 'valid, but full snapshot that can at least be 
utilized read-only'.  The alternate of letting it become invalid, such 
that the user can get the 'benefit' that if their current workload 
contains itself to chunks already managed in the snapshot, seems like no 
real benefit to me (maybe if a database was contained entirely within 
the snapshot chunks and the system was only fiddling with that).  Or 
perhaps I'm completely misunderstanding things (entirely possible)

-dmc



>
> Alasdair
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel