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
WARNING: multiple messages have this Message-ID (diff)
From: Joe Thornber <thornber@redhat.com>
To: lvm-devel@redhat.com
Subject: 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
WARNING: multiple messages have this Message-ID (diff)
From: Joe Thornber <thornber@redhat.com>
To: "Amir G." <amir73il@users.sourceforge.net>
Cc: Lukas Czerner <lczerner@redhat.com>,
Mike Snitzer <snitzer@redhat.com>,
linux-ext4@vger.kernel.org, tytso@mit.edu,
linux-kernel@vger.kernel.org, lvm-devel@redhat.com,
linux-fsdevel <linux-fsdevel@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
next prev parent reply other threads:[~2011-06-11 7:35 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 18:26 LVM vs. Ext4 snapshots (was: [PATCH v1 00/30] Ext4 snapshots) Amir G.
2011-06-08 18:26 ` Amir G.
2011-06-08 18:49 ` Sunil Mushran
2011-06-09 2:05 ` Yongqiang Yang
2011-06-09 2:05 ` Yongqiang Yang
2011-06-09 10:52 ` Christoph Hellwig
2011-06-09 11:44 ` Amir G.
2011-06-09 11:44 ` Amir G.
2011-06-10 7:45 ` Amir G.
2011-06-10 7:45 ` Amir G.
2011-06-10 8:08 ` Amir G.
2011-06-10 8:08 ` Amir G.
2011-06-10 9:01 ` Lukas Czerner
2011-06-10 9:01 ` Lukas Czerner
2011-06-10 10:11 ` Joe Thornber
2011-06-10 10:11 ` Joe Thornber
2011-06-10 10:11 ` Joe Thornber
2011-06-10 14:15 ` Amir G.
2011-06-10 14:15 ` Amir G.
2011-06-10 14:15 ` Amir G.
2011-06-10 15:01 ` Joe Thornber
2011-06-10 15:01 ` Joe Thornber
2011-06-10 15:01 ` Joe Thornber
2011-06-11 4:01 ` Amir G.
2011-06-11 4:01 ` Amir G.
2011-06-11 4:01 ` Amir G.
2011-06-11 7:49 ` Joe Thornber
2011-06-11 7:49 ` Joe Thornber
2011-06-11 7:49 ` Joe Thornber
2011-06-11 8:18 ` Alex Bligh
2011-06-11 8:18 ` Alex Bligh
2011-06-11 9:44 ` Amir G.
2011-06-11 9:44 ` Amir G.
2011-06-11 5:41 ` Amir G.
2011-06-11 5:41 ` Amir G.
2011-06-11 7:35 ` Joe Thornber [this message]
2011-06-11 7:35 ` Joe Thornber
2011-06-11 7:35 ` Joe Thornber
2011-06-11 9:58 ` Amir G.
2011-06-11 9:58 ` Amir G.
2011-06-11 9:58 ` Amir G.
2011-06-13 8:50 ` Joe Thornber
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 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.