From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m3OHKH2i026218 for ; Thu, 24 Apr 2008 13:20:17 -0400 Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.225]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m3OHK0FS022372 for ; Thu, 24 Apr 2008 13:20:03 -0400 Received: by hu-out-0506.google.com with SMTP id 19so2568693hue.21 for ; Thu, 24 Apr 2008 10:20:00 -0700 (PDT) Message-ID: <1c748a490804241019l30e33fceyfd6b410119f94e15@mail.gmail.com> Date: Thu, 24 Apr 2008 10:19:56 -0700 From: "Larry Dickson" Subject: Re: [linux-lvm] Snapshot question... [scaling problem] In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6438_1095271.1209057596567" References: <1c748a490804240721g639303d8g5b5071dea15332bb@mail.gmail.com> Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: LVM general discussion and development ------=_Part_6438_1095271.1209057596567 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline >Then you can't delete an older snapsnot until you delete all newer ones. Not true of what I was proposing - are we talking past each other? If snap 0 is the current (live) COW, and snap -k refers to time(-k) = time(snap 0) - k*(interval), then reading the virtual data for time(-k) involves looking at snap -k, then snap -k+1, ... snap 0, current data; but stopping the first time your block gets a hit. The only point with a race is {snap 0, current data}. So you can't delete a NEWER snapshot until you delete all OLDER ones (because the virtual older snaps need the newer COWs). That seems a small price to pay, since normally you throw them away oldest first. Larry On 4/24/08, Stuart D. Gathman wrote: > > On Thu, 24 Apr 2008, Larry Dickson wrote: > > > There's an almost trivial variant on this, where you keep the > > (read-only) snapshots in a time-ordered sequence, and freeze the last > > snapshot COW at the same moment as you start the next snapshot. Then > writing > > only ever hits the new snapshot COW, and reading from any older snapshot > > (virtual) volume involves figuring out which is the first after that to > hold > > the block, but still involves reading only one block. I wonder why LVM > does > > not do this. Perhaps Zumastor does? Or somebody else? > > Then you can't delete an older snapsnot until you delete all newer ones. > > Zumastor works by using one COW table shared between all snapshots > for a volume. Blocks are added to the COW in time order. The origin > ignores COW blocks before the last time point (block offset), writing a > new COW > block for any modified since that time point. The snapshots also use > timepoints in a way that is straightforward, but I don't want to think > about it at the moment :-) > > -- > Stuart D. Gathman > Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 > "Confutatis maledictis, flammis acribus addictis" - background song for > a Microsoft sponsored "Where do you want to go from here?" commercial. > > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > ------=_Part_6438_1095271.1209057596567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
>Then you can't delete an older snapsnot until you delete all newer ones.
 
Not true of what I was proposing - are we talking past each other? If snap 0 is the current (live) COW, and snap -k refers to time(-k) = time(snap 0) - k*(interval), then reading the virtual
data for time(-k) involves looking at snap -k, then snap -k+1, ... snap 0, current data; but stopping the first time your block gets a hit. The only point with a race is {snap 0, current data}. So you can't delete a NEWER snapshot until you delete all OLDER ones (because the virtual older snaps need the newer COWs). That seems a small price to pay, since normally you throw them away oldest first.
 
Larry
 
On 4/24/08, Stuart D. Gathman <stuart@bmsi.com> wrote:
On Thu, 24 Apr 2008, Larry Dickson wrote:

> There's an almost trivial variant on this, where you keep the
> (read-only) snapshots in a time-ordered sequence, and freeze the last
> snapshot COW at the same moment as you start the next snapshot. Then writing
> only ever hits the new snapshot COW, and reading from any older snapshot
> (virtual) volume involves figuring out which is the first after that to hold
> the block, but still involves reading only one block. I wonder why LVM does
> not do this. Perhaps Zumastor does? Or somebody else?

Then you can't delete an older snapsnot until you delete all newer ones.

Zumastor works by using one COW table shared between all snapshots
for a volume.  Blocks are added to the COW in time order.  The origin
ignores COW blocks before the last time point (block offset), writing a new COW
block for any modified since that time point.  The snapshots also use
timepoints in a way that is straightforward, but I don't want to think
about it at the moment :-)

--
             Stuart D. Gathman <stuart@bmsi.com>
   Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

------=_Part_6438_1095271.1209057596567--