[RFC] Out of order snapshot deletion

[RFC] Out of order snapshot deletion

[Vijai Babu Madhavan]

Hi,

I thought I would bring this topic in a separate thread so that 
it can be discussed independently.

As users start taking a bunch of snapshots and keep them as 
backups, we see the following use pattern when the snapshots 
get recycled.

Different snapshots have different life cycle. When some one 
decides to keep 'x' snapshots, at the recycle phase, the least 
recent does not necessarily get deleted.

As users want to keep the daily snapshots for a much longer period
than the bi-hourly snapshots. In the same way, weekly snapshots 
live longer than daily snapshots.

I think this is pretty much similar to the way the current backup tapes
are managed.

I want to know if this is the kind of use case that users are having or 
the developers are thinking.

The reason why I am posting this is that this out of snapshot deletion
scenario, poses some interesting challenges in the design on the solution 
of multiple snapshots that share blocks with each other, as it is a lot easier 
to design a solution where the least recent gets deleted always.

Vijai

[linux-lvm] [RFC] Out of order snapshot deletion

[Vijai Babu Madhavan]

Hi,

I thought I would bring this topic in a separate thread so that 
it can be discussed independently.

As users start taking a bunch of snapshots and keep them as 
backups, we see the following use pattern when the snapshots 
get recycled.

Different snapshots have different life cycle. When some one 
decides to keep 'x' snapshots, at the recycle phase, the least 
recent does not necessarily get deleted.

As users want to keep the daily snapshots for a much longer period
than the bi-hourly snapshots. In the same way, weekly snapshots 
live longer than daily snapshots.

I think this is pretty much similar to the way the current backup tapes
are managed.

I want to know if this is the kind of use case that users are having or 
the developers are thinking.

The reason why I am posting this is that this out of snapshot deletion
scenario, poses some interesting challenges in the design on the solution 
of multiple snapshots that share blocks with each other, as it is a lot easier 
to design a solution where the least recent gets deleted always.

Vijai

Re: [dm-devel] [RFC] Out of order snapshot deletion

[Ming Zhang]

On Thu, 2007-01-11 at 22:19 -0700, Vijai Babu Madhavan wrote:
> Hi,
> 
> I thought I would bring this topic in a separate thread so that 
> it can be discussed independently.
> 
> As users start taking a bunch of snapshots and keep them as 
> backups, we see the following use pattern when the snapshots 
> get recycled.
> 
> Different snapshots have different life cycle. When some one 
> decides to keep 'x' snapshots, at the recycle phase, the least 
> recent does not necessarily get deleted.
> 
> As users want to keep the daily snapshots for a much longer period
> than the bi-hourly snapshots. In the same way, weekly snapshots 
> live longer than daily snapshots.
> 
> I think this is pretty much similar to the way the current backup tapes
> are managed.

make sense.

> 
> I want to know if this is the kind of use case that users are having or 
> the developers are thinking.
> 
> The reason why I am posting this is that this out of snapshot deletion
> scenario, poses some interesting challenges in the design on the solution 
> of multiple snapshots that share blocks with each other, as it is a lot easier 
> to design a solution where the least recent gets deleted always.

this does not hold true. for snapshot used as backup purpose, you 100%
can not assume the oldest or newest will be delete first. there is no
such rule.

and possibly, you create one snapshot base on policy and later mount it
and check data consistency. if it turns out to be a bad one, you want to
delete it. then you have no order to follow at all.

ps, any comment on http://sourceware.org/cluster/csnap/? this also try
to solve the current multiple snapshot issues.

thanks

Ming

> 
> Vijai
> 
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
-- 
http://blackmagic02881.wordpress.com/


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Evms-devel mailing list
Evms-devel@lists.sourceforge.net
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel

[linux-lvm] Re: [dm-devel] [RFC] Out of order snapshot deletion

[Ming Zhang]

On Thu, 2007-01-11 at 22:19 -0700, Vijai Babu Madhavan wrote:
> Hi,
> 
> I thought I would bring this topic in a separate thread so that 
> it can be discussed independently.
> 
> As users start taking a bunch of snapshots and keep them as 
> backups, we see the following use pattern when the snapshots 
> get recycled.
> 
> Different snapshots have different life cycle. When some one 
> decides to keep 'x' snapshots, at the recycle phase, the least 
> recent does not necessarily get deleted.
> 
> As users want to keep the daily snapshots for a much longer period
> than the bi-hourly snapshots. In the same way, weekly snapshots 
> live longer than daily snapshots.
> 
> I think this is pretty much similar to the way the current backup tapes
> are managed.

make sense.

> 
> I want to know if this is the kind of use case that users are having or 
> the developers are thinking.
> 
> The reason why I am posting this is that this out of snapshot deletion
> scenario, poses some interesting challenges in the design on the solution 
> of multiple snapshots that share blocks with each other, as it is a lot easier 
> to design a solution where the least recent gets deleted always.

this does not hold true. for snapshot used as backup purpose, you 100%
can not assume the oldest or newest will be delete first. there is no
such rule.

and possibly, you create one snapshot base on policy and later mount it
and check data consistency. if it turns out to be a bad one, you want to
delete it. then you have no order to follow at all.

ps, any comment on http://sourceware.org/cluster/csnap/? this also try
to solve the current multiple snapshot issues.

thanks

Ming

> 
> Vijai
> 
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
-- 
http://blackmagic02881.wordpress.com/

RE: [RFC] Out of order snapshot deletion

[Wilson, Christopher J]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4552 bytes --]

My opinion is that "snapshots" should be less persistent than full clone
copies.  Longer term retention should move to full clone then you don't
have the snapshot overhead you've raised on your other thread.  I can't
imagine that there are so many administrators out there wanting to
maintain week old snapshots.  Those older ones would most likely have
been mounted somewhere and spooled to tape.  I could be way off base but
I'd not feel so confident in a week old cow as I would with a week old
clone.

We here have been tossing around the idea of treating snapshot (or full
clone) as backup media.  Media that would contain a barcode and which
could be migrated to physical tape.  Currently this is the realm of VTL.
VTL is a copy of your data written out in a sequential manner, if you
could somehow create disk media via snapshot that the disk caches
(Falconstor, Sepaton) use then you could get the long sequential
read/write overhead out of the backup application and the host.

Our issue with snapshot, as I mentioned on the other thread, is that
there are no close ties to the upper level applications, this includes
backup software like NetBackup and Legato.  NetBackup has the "virtual
backup" piece but I've not really seen it implemented.  Ideally an
interface for a database application to take a snapshot of its data and
call it barcode xxxx03 could then be imported into your backup
application as a virtual tape xxxx03.  That "tape" could be cloned via
NetBackup or disk cache software to real tape with barcode xxxx03 for
off site storage (through an encryption device of course).  I know there
are data alignment issues that exist here with data sizes and physical
tape sizes but we believe it's an avenue worth exploring.

There are several opportunities to better admin quality of life here.
One is that backup administrators would be able to continually manage
their media in what they know, tapes with barcodes they can touch and
feel.  The other is DBA's could maintain a list of snapshots through
something other than "glue code".  It would integrate into the processes
that exist around data protection.

Christopher Wilson
Storage Architect
Verizon Business
IT Solutions - IP Application Hosting
240 264 4136
vnet: 364 4136

 

-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On Behalf Of Vijai Babu Madhavan
Sent: Friday, January 12, 2007 12:19 AM
To: evms-devel@lists.sourceforge.net; dm-devel@redhat.com;
linux-lvm@redhat.com
Subject: [dm-devel] [RFC] Out of order snapshot deletion

Hi,

I thought I would bring this topic in a separate thread so that it can
be discussed independently.

As users start taking a bunch of snapshots and keep them as backups, we
see the following use pattern when the snapshots get recycled.

Different snapshots have different life cycle. When some one decides to
keep 'x' snapshots, at the recycle phase, the least recent does not
necessarily get deleted.

As users want to keep the daily snapshots for a much longer period than
the bi-hourly snapshots. In the same way, weekly snapshots live longer
than daily snapshots.

I think this is pretty much similar to the way the current backup tapes
are managed.

I want to know if this is the kind of use case that users are having or
the developers are thinking.

The reason why I am posting this is that this out of snapshot deletion
scenario, poses some interesting challenges in the design on the
solution of multiple snapshots that share blocks with each other, as it
is a lot easier to design a solution where the least recent gets deleted
always.

Vijai


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

______________________________________________________________________
This e-mail has been scanned by Verizon Managed Email Content Service,
using Skeptic(tm) technology powered by MessageLabs. For more
information on Verizon Managed Email Content Service, visit
http://www.verizonbusiness.com.
______________________________________________________________________


______________________________________________________________________
This e-mail has been scanned by Verizon Managed Email Content Service, using Skeptic™ technology powered by MessageLabs. For more information on Verizon Managed Email Content Service, visit http://www.verizonbusiness.com.
______________________________________________________________________

[linux-lvm] RE: [dm-devel] [RFC] Out of order snapshot deletion

[Wilson, Christopher J]

My opinion is that "snapshots" should be less persistent than full clone
copies.  Longer term retention should move to full clone then you don't
have the snapshot overhead you've raised on your other thread.  I can't
imagine that there are so many administrators out there wanting to
maintain week old snapshots.  Those older ones would most likely have
been mounted somewhere and spooled to tape.  I could be way off base but
I'd not feel so confident in a week old cow as I would with a week old
clone.

We here have been tossing around the idea of treating snapshot (or full
clone) as backup media.  Media that would contain a barcode and which
could be migrated to physical tape.  Currently this is the realm of VTL.
VTL is a copy of your data written out in a sequential manner, if you
could somehow create disk media via snapshot that the disk caches
(Falconstor, Sepaton) use then you could get the long sequential
read/write overhead out of the backup application and the host.

Our issue with snapshot, as I mentioned on the other thread, is that
there are no close ties to the upper level applications, this includes
backup software like NetBackup and Legato.  NetBackup has the "virtual
backup" piece but I've not really seen it implemented.  Ideally an
interface for a database application to take a snapshot of its data and
call it barcode xxxx03 could then be imported into your backup
application as a virtual tape xxxx03.  That "tape" could be cloned via
NetBackup or disk cache software to real tape with barcode xxxx03 for
off site storage (through an encryption device of course).  I know there
are data alignment issues that exist here with data sizes and physical
tape sizes but we believe it's an avenue worth exploring.

There are several opportunities to better admin quality of life here.
One is that backup administrators would be able to continually manage
their media in what they know, tapes with barcodes they can touch and
feel.  The other is DBA's could maintain a list of snapshots through
something other than "glue code".  It would integrate into the processes
that exist around data protection.

Christopher Wilson
Storage Architect
Verizon Business
IT Solutions - IP Application Hosting
240 264 4136
vnet: 364 4136

 

-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On Behalf Of Vijai Babu Madhavan
Sent: Friday, January 12, 2007 12:19 AM
To: evms-devel@lists.sourceforge.net; dm-devel@redhat.com;
linux-lvm@redhat.com
Subject: [dm-devel] [RFC] Out of order snapshot deletion

Hi,

I thought I would bring this topic in a separate thread so that it can
be discussed independently.

As users start taking a bunch of snapshots and keep them as backups, we
see the following use pattern when the snapshots get recycled.

Different snapshots have different life cycle. When some one decides to
keep 'x' snapshots, at the recycle phase, the least recent does not
necessarily get deleted.

As users want to keep the daily snapshots for a much longer period than
the bi-hourly snapshots. In the same way, weekly snapshots live longer
than daily snapshots.

I think this is pretty much similar to the way the current backup tapes
are managed.

I want to know if this is the kind of use case that users are having or
the developers are thinking.

The reason why I am posting this is that this out of snapshot deletion
scenario, poses some interesting challenges in the design on the
solution of multiple snapshots that share blocks with each other, as it
is a lot easier to design a solution where the least recent gets deleted
always.

Vijai


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

______________________________________________________________________
This e-mail has been scanned by Verizon Managed Email Content Service,
using Skeptic(tm) technology powered by MessageLabs. For more
information on Verizon Managed Email Content Service, visit
http://www.verizonbusiness.com.
______________________________________________________________________


______________________________________________________________________
This e-mail has been scanned by Verizon Managed Email Content Service, using Skeptic� technology powered by MessageLabs. For more information on Verizon Managed Email Content Service, visit http://www.verizonbusiness.com.
______________________________________________________________________

Re: [RFC] Out of order snapshot deletion

[Benjamin Marzinski]

On Thu, Jan 11, 2007 at 10:19:06PM -0700, Vijai Babu Madhavan wrote:
> Hi,
> 
> I thought I would bring this topic in a separate thread so that 
> it can be discussed independently.
> 
> As users start taking a bunch of snapshots and keep them as 
> backups, we see the following use pattern when the snapshots 
> get recycled.
> 
> Different snapshots have different life cycle. When some one 
> decides to keep 'x' snapshots, at the recycle phase, the least 
> recent does not necessarily get deleted.
> 
> As users want to keep the daily snapshots for a much longer period
> than the bi-hourly snapshots. In the same way, weekly snapshots 
> live longer than daily snapshots.
> 
> I think this is pretty much similar to the way the current backup tapes
> are managed.
> 
> I want to know if this is the kind of use case that users are having or 
> the developers are thinking.
> 
> The reason why I am posting this is that this out of snapshot deletion
> scenario, poses some interesting challenges in the design on the solution 
> of multiple snapshots that share blocks with each other, as it is a lot easier> to design a solution where the least recent gets deleted always.

Here are my best recollections of how it does (or at least could)
work in Daniel's design that I mentioned in the last thread.

The list of currently valid snapshots is stored as a bitmask, both in the
exceptions, and in the snapstore superblock.  There are two ways to deal with
deletion.

The easy (and slower) way, is to halt all writes that need to use the btree.
Then you turn off that device's bit in the snapstore superblock, and walkt the
btree, freeing up exceptions that are unique to that device, or removing from
the bitmap of shared exceptions. Then you let access to the btree continue.

There is a more complicated method that seems like it should still be doable,
and allows you to do a lazy deletion.  To start with, you just turn off that
device's bit in the snapstore superblock. When the origin checks to see if
all the snapshots have exceptions, or a snapshot checks if it is the only
holder of an exception, they can simply mask the exception bitmask with the
origin bitmask. This will cause the deleted snapshot to be ignored.  Then
a daemon could lazily go through and clear that bit from all the exceptions.
Of course, until the bit is cleared up from all the exceptions, that bit must
not be used by any newly created snapshots. This could be done by simply storing
two bitmaps. The first would clear the deleted snapshot's bit on deletion as
described above. The second would only clear the deleted snapshot's bit after
it had been cleared from the exception btree.

In both of these methods, it is just as easy to delete any snapshot as any other
one. I don't know if snapshots get deleted often enough for the added complexityof the second method to be worth it.

-Ben


> Vijai
> 
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel