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

[Frederick Grose]

On Sun, Nov 27, 2011 at 8:08 PM, Douglas McClendon <
dmc.lists at filteredperception.org> wrote:

> On 11/27/2011 04:31 PM, Frederick Grose wrote:
>
>> On Sat, Oct 29, 2011 at 4:49 PM, Alasdair G Kergon <agk at redhat.com
>> <mailto:agk at redhat.com>> wrote:
>>
>>    markmc did some code that shows how to read the format a few years
>>    ago here:
>>    http://people.gnome.org/~**markmc/code/merge-dm-snapshot.**c<http://people.gnome.org/~markmc/code/merge-dm-snapshot.c>
>>    <http://people.gnome.org/%**7Emarkmc/code/merge-dm-**snapshot.c<http://people.gnome.org/%7Emarkmc/code/merge-dm-snapshot.c>
>> >
>>
>>
>>    Otherwise look at dm-snap-persistent.c in the kernel tree.
>>
>>    Alasdair
>>
>>
>> Users can easily exhaust a LiveUSB snapshot overlay by writing
>> too many changes to the OS filesystem, such as by performing
>> a yum update.
>>
>> Would such an 'exhausted' overlay be amenable to some sort of
>> data recovery or forensics?
>>
>> If so, how so; if not, why not?
>>
>
> Can you not mount the exhausted dm snapshot?  If you mean data recovery or
> forensics beyond that, please elaborate.
>
> I know I've had issues 'read-only' mounting ext3(2?3?4?) filesystems
> before (on actually read-only block devices).  Maybe some flags that I've
> forgotten get past that, but worst case you can always fake a writable
> device with a 2nd overlay/snapshot going to a writable device, i.e. if you
> wanted to let fsck repair things.
>
> -dmc


A typical scenario goes like this:

A LiveCD is loaded onto a USB device with a relatively small
persistent overlay and no separate home.img filesystem.  The user
proceeds to use the system and save some information.  They may
execute a df command and see that there is lots of space
available on the rootfs.  Then they decide to execute a yum
update or yum install when there is insufficient space available.
(They do not know about dmsetup status.)  Their session will now
not shutdown normally. dmsetup status now shows

live-rw: 0 8388608 snapshot Invalid.

The device fails to complete a subsequent boot attempt.  The
startup log shows

mount: /dev/mapper/live-rw: can't read superblock

e2fsck /dev/dm-0 shows

Buffer I/O error on device dm-0, logical block 0 (and 1, 2, 3, 0)
e2fsck: Attempt to read block from the filesystem resulted in
short read while trying to open /dev/dm-0
Could this be a zero-length partition?

I recreated the above scenario on Fedora-16-Live-Desktop
installed with an overlay-size-mb of 100.  After updating to ~70%
of the overlay, I wrote with
dd if=/dev/zero of=/boot/load bs=1M count=10
3 times to exhaust the overlay.

With the defective device mounted on a good system, and loop
devices set up for ext3fs.img and the overlay file,

dmsetup create item --table "0 8388608 snapshot 7:1 7:2 P 8"
reports
item: 0 8388608 snapshot Invalid

e2fsck /dev/dm-0 reports

e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Attempt to read block from filesystem resulted in short
read while trying to open /dev/dm-0
Could this be a zero-length partition?

A hex editor view of the overlay file shows lots of content with
lots of zeros at the end of the file.

My questions are these:

Might there be a way to edit the overlay file to restore its
utility for the information written before the damaging write?

If so, how so; if not, why not?

Suitable references would do as well.

Thanks!       --Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20111129/e7dddb8c/attachment.htm>