[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] DM_snapshot_cow filesystem (dmsetup create snapshot)

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)



dm-devel mailing list
dm-devel redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]