All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas McClendon <dmc.lists@filteredperception.org>
To: dm-devel@redhat.com
Subject: Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
Date: Sun, 27 Nov 2011 19:08:31 -0600	[thread overview]
Message-ID: <4ED2DF0F.1070108@filteredperception.org> (raw)
In-Reply-To: <CAEcBt+Ux+GVmm7zBeFA7k5PHOQoSKLTKcifB95ne5dBtX400dQ@mail.gmail.com>

On 11/27/2011 04:31 PM, Frederick Grose wrote:
> On Sat, Oct 29, 2011 at 4:49 PM, Alasdair G Kergon <agk@redhat.com
> <mailto:agk@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/%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

  reply	other threads:[~2011-11-28  1:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-29 11:19 DM_snapshot_cow filesystem (dmsetup create snapshot) Mr Dash Four
2011-10-29 20:49 ` Alasdair G Kergon
2011-11-27 22:31   ` Frederick Grose
2011-11-28  1:08     ` Douglas McClendon [this message]
2011-11-29  6:22       ` Frederick Grose
2011-11-30  2:09         ` Douglas McClendon
2011-11-30 21:48           ` Frederick Grose
2011-11-30 22:03             ` Alasdair G Kergon
2011-11-30 23:34               ` Douglas McClendon
2011-12-01 14:12                 ` Alasdair G Kergon
2011-12-01 20:18                   ` Douglas McClendon
2011-12-01 20:20                     ` Alasdair G Kergon
2011-12-01 20:26                       ` Douglas McClendon
2011-12-02  3:44                       ` Douglas McClendon
2011-12-02  8:46                         ` Alasdair G Kergon
2011-12-02 17:42                           ` Frederick Grose
2011-12-01 20:21                   ` Douglas McClendon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED2DF0F.1070108@filteredperception.org \
    --to=dmc.lists@filteredperception.org \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.