[Gluster-devel] autodelete in snapshots

Fri Apr 18 02:26:40 UTC 2014

No issue with this behaviour - makes sense. 

However, the point I made about snapdelete being invoked when thinpool free space is threatened is a very real issue once you start using snaps. for 3.6 basing snap management on snapshot versions is fine, but I do think this needs to be extended to account for the thinpool freespace too in a subsequent release. 

Maybe you already have it in plan? 

----- Original Message -----

> From: "Rahul Hinduja" <rhinduja at redhat.com>
> To: "Avra Sengupta" <asengupt at redhat.com>
> Cc: "Seema Naik" <senaik at redhat.com>, "gluster-devel"
> <gluster-devel at nongnu.org>
> Sent: Tuesday, 15 April, 2014 11:35:19 PM
> Subject: Re: [Gluster-devel] autodelete in snapshots

> ----- Original Message -----
> > From: "Avra Sengupta" <asengupt at redhat.com>
> > To: "Lalatendu Mohanty" <lmohanty at redhat.com>, "Raghavendra Bhat"
> > <rabhat at redhat.com>, "gluster-devel"
> > <gluster-devel at nongnu.org>, "Rahul Hinduja" <rhinduja at redhat.com>, "Seema
> > Naik" <senaik at redhat.com>
> > Sent: Wednesday, April 16, 2014 11:39:11 AM
> > Subject: Re: [Gluster-devel] autodelete in snapshots
> >
> > The whole purpose of introducing the soft-limit is, that at any point of
> > time
> > the number of
> > snaps should not exceed the hard limit. If we trigger auto-delete on
> > hitting
> > hard-limit, then
> > the purpose itself is lost, because at that point we would be taking a
> > snap,
> > making the limit
> > hard-limit + 1, and then triggering auto-delete, which violates the
> > sanctity
> > of the hard-limit.
> > Also what happens when we are at hard-limit + 1, and another snap is
> > issued,
> > while auto-delete
> > is yet to process the first delete. At that point we end up at hard-limit +
> > 1. Also what happens
> > if for a particular snap the auto-delete fails.
> >
> > We should see the hard-limit, as something set by the admin keeping in mind
> > the resource consumption
> > and at no-point should we cross this limit, come what may. If we hit this
> > limit, the create command
> > should fail asking the user to delete snaps using the "snapshot delete"
> > command.
> >
> > The two options Raghavendra mentioned are applicable for the soft-limit
> > only,
> > in which cases on
> > hitting the soft-limit
> >
> > 1. Trigger auto-delete
> >
> > or
> >
> > 2. Log a warning-message, for the user saying the number of snaps is
> > exceeding the snap-limit and
> > display the number of available snaps
> >
> > Now which of these should happen also depends on the user, because the
> > auto-delete option
> > is configurable.
> >
> > So if the auto-delete option is set as true, auto-delete should be
> > triggered
> > and the above message
> > should also be logged.
> >
> > But if the option is set as false, only the message should be logged.
> >
> > This is the behaviour as designed. Adding Rahul, and Seema in the mail, to
> > reflect upon the
> > behaviour as well.

> Agreed with Avra, the purpose of introducing soft limits and hard limits was
> to restrict snap creation to reach limit+1 at any point in time. Any time
> the limit reaches the hard limit the subsequent creation should fail. Once
> the limit reaches the soft limit the auto-delete starts in background. Since
> soft-limit is configurable option between 1-100, it really gives flexibility
> to the user to start the auto-deletion based on his requirement it can be at
> 1% or even 100% soft-limit.

> If the auto-delete option is set to true than it should be triggered and
> should log message based on user's input of soft-limit and if it is set to
> false the auto-delete should only log message and snap creation fails when
> it reaches the hard-limit.

> Thanks,
> Rahul

> >
> > Regards,
> > Avra
> >
> > On 04/15/2014 07:18 PM, Lalatendu Mohanty wrote:
> >
> > > On 04/15/2014 07:05 PM, Raghavendra Bhat wrote:
> > >>
> > >> Hi,
> > >>
> > >> As of now, in snapshots there are 2 limits for the number of
> > >> snapshots, hard-limit and soft-limit. Usually soft-limit is 90% of
> > >> hard-limit by default (it can be changed also). Say the hard-limit is
> > >> 50, then soft-limit by default will be 45. We are planning to do
> > >> autodelete of the oldest snapshot upon reaching the limit.
> > >>
> > >> There are 2 options:
> > >>
> > >> 1) Start doing autodelete upon reaching the soft-limit. i.e If the
> > >> hard limit is 50 and the number of the snapshots taken becomes 45,
> > >> then for the next snapshot taken (i.e 46th snapshot), the oldest
> > >> snapshot will be automatically deleted in the background.
> > >>
> > >> 2) Use soft-limit as a means to notify the admin about limit being
> > >> reached (gf_log, syslog etc, or also a warning message shown for
> > >> every snapshot taken after the soft limit is reached) and start doing
> > >> autodelete after reaching the hard-limit i.e once 50 snapshots are
> > >> reached, then when 51st snapshot is triggered, the oldest snapshot
> > >> will be deleted in the background.
> > >>
> > >> Please provide feedback.
> > >
> > > I like the #2 option. If user has set something as hard-limit, it
> > > should be treated as hard limit and soft-limit can be used as warning
> > > mechanism.
> > >
> > >>
> > >> NOTE: The auto-delete can be made configurable, which if turned off,
> > >> snapshot create fails upon reaching the limit.
> > >>
> > >> Regards,
> > >> Raghavendra Bhat
> > >>
> > >> _______________________________________________
> > >> Gluster-devel mailing list
> > >> Gluster-devel at nongnu.org
> > >> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> > >
> > >
> > > _______________________________________________
> > > Gluster-devel mailing list
> > > Gluster-devel at nongnu.org
> > > https://lists.nongnu.org/mailman/listinfo/gluster-devel
> >
> >

> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140417/eb047fbb/attachment-0001.html>