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: Mon, 13 Jun 2011 09:50:55 +0100 [thread overview]
Message-ID: <20110613085054.GA4580@ubuntu> (raw)
In-Reply-To: <BANLkTi=THJi8Z2RTdfGgox4NH8hEGiN37A@mail.gmail.com>
On Sat, Jun 11, 2011 at 12:58:26PM +0300, Amir G. wrote:
> I meant _readonly_ snapshots of a _writable_ _external_ origin,
> which is what ext4 snapshots provides.
> All snapshots are chained on a list that points to the origin and
> only the latest (active) snapshot metadata get updated on origin writes.
> When older snapshots lookup return -ENODATA, you go up the list
> to the newer snapshot and up to the origin.
>
> Those _incremental_ snapshots cannot be _writable_, because older
> snapshots may implicitly share blocks with newer snapshots, but it should
> be possible to make _writable_ clones of these snapshots.
> Not sure what the implications are for deleting snapshots, because I am
> not familiar with all the implementation details of multisnap.
I deliberately ruled out chaining schemes like this because I want to
support large numbers of snapshots. I believe Daniel Phillips
described a chaining scheme a while ago, and someone else implemented
it last year. From a cursory glance through the code they posted on
dm-devel, it appeared to need a large in memory hash table to cache
all those chained lookups.
- Joe
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: Mon, 13 Jun 2011 09:50:55 +0100 [thread overview]
Message-ID: <20110613085054.GA4580@ubuntu> (raw)
In-Reply-To: <BANLkTi=THJi8Z2RTdfGgox4NH8hEGiN37A@mail.gmail.com>
On Sat, Jun 11, 2011 at 12:58:26PM +0300, Amir G. wrote:
> I meant _readonly_ snapshots of a _writable_ _external_ origin,
> which is what ext4 snapshots provides.
> All snapshots are chained on a list that points to the origin and
> only the latest (active) snapshot metadata get updated on origin writes.
> When older snapshots lookup return -ENODATA, you go up the list
> to the newer snapshot and up to the origin.
>
> Those _incremental_ snapshots cannot be _writable_, because older
> snapshots may implicitly share blocks with newer snapshots, but it should
> be possible to make _writable_ clones of these snapshots.
> Not sure what the implications are for deleting snapshots, because I am
> not familiar with all the implementation details of multisnap.
I deliberately ruled out chaining schemes like this because I want to
support large numbers of snapshots. I believe Daniel Phillips
described a chaining scheme a while ago, and someone else implemented
it last year. From a cursory glance through the code they posted on
dm-devel, it appeared to need a large in memory hash table to cache
all those chained lookups.
- Joe
next prev parent reply other threads:[~2011-06-13 8:51 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
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 [this message]
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=20110613085054.GA4580@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.