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:<http://people.gnome.org/%7Emarkmc/code/merge-dm-snapshot.c>
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
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
