<div>>Then you can't delete an older snapsnot until you delete all newer ones.<br> </div>
<div>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</div>
<div>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.</div>

<div> </div>
<div>Larry<br> </div>
<div><span class="gmail_quote">On 4/24/08, <b class="gmail_sendername">Stuart D. Gathman</b> <<a href="mailto:stuart@bmsi.com">stuart@bmsi.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Thu, 24 Apr 2008, Larry Dickson wrote:<br><br>> There's an almost trivial variant on this, where you keep the<br>
> (read-only) snapshots in a time-ordered sequence, and freeze the last<br>> snapshot COW at the same moment as you start the next snapshot. Then writing<br>> only ever hits the new snapshot COW, and reading from any older snapshot<br>
> (virtual) volume involves figuring out which is the first after that to hold<br>> the block, but still involves reading only one block. I wonder why LVM does<br>> not do this. Perhaps Zumastor does? Or somebody else?<br>
<br>Then you can't delete an older snapsnot until you delete all newer ones.<br><br>Zumastor works by using one COW table shared between all snapshots<br>for a volume.  Blocks are added to the COW in time order.  The origin<br>
ignores COW blocks before the last time point (block offset), writing a new COW<br>block for any modified since that time point.  The snapshots also use<br>timepoints in a way that is straightforward, but I don't want to think<br>
about it at the moment :-)<br><br>--<br>             Stuart D. Gathman <<a href="mailto:stuart@bmsi.com">stuart@bmsi.com</a>><br>   Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154<br>"Confutatis maledictis, flammis acribus addictis" - background song for<br>
a Microsoft sponsored "Where do you want to go from here?" commercial.<br><br>_______________________________________________<br>linux-lvm mailing list<br><a href="mailto:linux-lvm@redhat.com">linux-lvm@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/linux-lvm">https://www.redhat.com/mailman/listinfo/linux-lvm</a><br>read the LVM HOW-TO at <a href="http://tldp.org/HOWTO/LVM-HOWTO/">http://tldp.org/HOWTO/LVM-HOWTO/</a><br>
</blockquote></div><br>