On 12/01/2011 02:20 PM, Alasdair G Kergon wrote:
On Thu, Dec 01, 2011 at 02:18:37PM -0600, Douglas McClendon wrote:
The overlay device in this situation is a read-write tmpfile in tmpfs,
looped to be available as the dm-snapshot 'snapshot/overlay device'.
Ah - well if your base device is already read-only, then there is no
corruption and you should be able to edit the bit of the disk image
that says 'this image is invalid' and recover it read-only or extend it.
The commandline to do the 'edit' was requested for users like Fred, and
because I guess one day I might find myself wanting to do the same.
As per possibly avoiding the need for such a workaround, and thinking
about the non-read-only base situation, does the following request sound
at least logically consistent, and correct in its assumptions-
Currently in a dm-snapshot case such as the fedora liveusb, the instant
a persistent snapshot becomes full, it is marked as invalid, and further
accesses result in (fixme?). But it would be preferable if instead of
being marked invalid at the instant it fills up, it is instead marked as
invalid at the first instant after it is full, and its base device gets
written to. And beyond that as a second change from the current state
of things, the virtual device using the overlay falls into a read-only
state the instant the overlay it is using reaches a full state.
(instead of as happens now ?? maybe selective write failures based on
whether or not the write destination is in a chunk within the full
overlay ??)
Thus in read-only base cases, the overlay never gets marked as invalid,
and no users have any need for a workaround tool or commandline to flip
the invalid bit(?) to valid, in order to mount and use/recover the data
present in the snapshot.
-dmc
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
