Re: DM_snapshot_cow filesystem (dmsetup create snapshot)

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

 



On Sun, Nov 27, 2011 at 8:08 PM, Douglas McClendon <dmc.lists@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On 11/27/2011 04:31 PM, Frederick Grose wrote:
On Sat, Oct 29, 2011 at 4:49 PM, Alasdair G Kergon <agk@xxxxxxxxxx
<mailto:agk@xxxxxxxxxx>> 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/%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


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

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux