From: Joe Thornber <thornber@redhat.com>
To: "Amir G." <amir73il@users.sourceforge.net>
Cc: tytso@mit.edu, Mike Snitzer <snitzer@redhat.com>,
linux-kernel@vger.kernel.org, lvm-devel@redhat.com,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Lukas Czerner <lczerner@redhat.com>,
linux-ext4@vger.kernel.org
Subject: Re: LVM vs. Ext4 snapshots (was: [PATCH v1 00/30] Ext4 snapshots)
Date: Sat, 11 Jun 2011 08:35:17 +0100 [thread overview]
Message-ID: <20110611073517.GB2517@ubuntu> (raw)
In-Reply-To: <BANLkTi=0N7QXRvFgjHUJXBi0x=668ahXXA@mail.gmail.com>
On Sat, Jun 11, 2011 at 08:41:38AM +0300, Amir G. wrote:
> On Fri, Jun 10, 2011 at 1:11 PM, Joe Thornber <thornber@redhat.com> wrote:
> > On Fri, Jun 10, 2011 at 11:01:41AM +0200, Lukas Czerner wrote:
> >> On Fri, 10 Jun 2011, Amir G. wrote:
> >>
> >> > CC'ing lvm-devel and fsdevel
> >> >
> >> >
> >> > On Wed, Jun 8, 2011 at 9:26 PM, Amir G. <amir73il@users.sourceforge.net> wrote:
> >> > For the sake of letting everyone understand the differences and trade
> >> > offs between
> >> > LVM and ext4 snapshots, so ext4 snapshots can get a fair trial, I need
> >> > to ask you
> >> > some questions about the implementation, which I could not figure out by myself
> >> > from reading the documents.
> >
> > First up let me say that I'm not intending to support writeable
> > _external_ origins with multisnap. This will come as a suprise to
> > many people, but I don't think we can resolve the dual requirements to
> > efficiently update many, many snapshots when a write occurs _and_ make
> > those snapshots quick to delete (when you're encouraging people to
> > take lots of snapshots performance of delete becomes a real issue).
> >
>
> If I understand this article correctly:
> http://people.redhat.com/mpatocka/papers/shared-snapshots.pdf
> It says that _external_ origin write updates can be efficient to readonly
> (or not written) snapshots.
>
> Could you not support readonly snapshots of an _external_ origin?
Yes, that is the intention, and very little work to add. We just do
something different if the metadata lookup returns -ENODATA. Above I
said I didn't intend to support _writeable_ external snaps. Readable
ones are a must, for instance for supporting virtual machine base
images.
> You could even support writable snapshots, that will degrade write
> performance to origin temporarily.
> It can be useful, if one wants to "try-out" mounting a temporary
> writable snapshot, when the origin is not even mounted.
> After the "try-out", the temporary snapshot can be deleted
> and origin write performance would go back to normal.
Not sure what you're getting at here. All snapshots are writeable.
Of course you can take a snapshot of an external origin and then use
this as your temporary origin for experiments. If the origin is
itself a dm device then LVM can shuffle tables around to make this
transparent.
The user may want to commit to their experiment at a later time by
merging back to the external origin. This involves copying, but no
more than a copy-on-write scheme. Arguably it's better to do the copy
only once we know they want to commit to it.
- Joe
--
lvm-devel mailing list
lvm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/lvm-devel
next prev parent reply other threads:[~2011-06-11 7:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BANLkTimyBGfg4+ovGsiGqpCz345qVmU_7A@mail.gmail.com>
[not found] ` <BANLkTik20iYN4c9faKD9dzerehazWTwTFw@mail.gmail.com>
2011-06-10 8:08 ` LVM vs. Ext4 snapshots (was: [PATCH v1 00/30] Ext4 snapshots) Amir G.
2011-06-10 9:01 ` Lukas Czerner
2011-06-10 10:11 ` Joe Thornber
2011-06-10 14:15 ` Amir G.
2011-06-10 15:01 ` Joe Thornber
2011-06-11 4:01 ` Amir G.
2011-06-11 7:49 ` Joe Thornber
2011-06-11 8:18 ` Alex Bligh
2011-06-11 9:44 ` Amir G.
2011-06-11 5:41 ` Amir G.
2011-06-11 7:35 ` Joe Thornber [this message]
2011-06-11 9:58 ` Amir G.
2011-06-13 8:50 ` Joe Thornber
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=20110611073517.GB2517@ubuntu \
--to=thornber@redhat.com \
--cc=amir73il@users.sourceforge.net \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lvm-devel@redhat.com \
--cc=snitzer@redhat.com \
--cc=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).