<html><body><div style="font-family: lucida console,sans-serif; font-size: 12pt; color: #000000"><div><br></div><div>No issue with this behaviour - makes sense.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Maybe you already have it in plan?<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Rahul Hinduja" <rhinduja@redhat.com><br><b>To: </b>"Avra Sengupta" <asengupt@redhat.com><br><b>Cc: </b>"Seema Naik" <senaik@redhat.com>, "gluster-devel" <gluster-devel@nongnu.org><br><b>Sent: </b>Tuesday, 15 April, 2014 11:35:19 PM<br><b>Subject: </b>Re: [Gluster-devel] autodelete in snapshots<br><div><br></div><br><div><br></div>----- Original Message -----<br>> From: "Avra Sengupta" <asengupt@redhat.com><br>> To: "Lalatendu Mohanty" <lmohanty@redhat.com>, "Raghavendra Bhat" <rabhat@redhat.com>, "gluster-devel"<br>> <gluster-devel@nongnu.org>, "Rahul Hinduja" <rhinduja@redhat.com>, "Seema Naik" <senaik@redhat.com><br>> Sent: Wednesday, April 16, 2014 11:39:11 AM<br>> Subject: Re: [Gluster-devel] autodelete in snapshots<br>> <br>> The whole purpose of introducing the soft-limit is, that at any point of time<br>> the number of<br>> snaps should not exceed the hard limit. If we trigger auto-delete on hitting<br>> hard-limit, then<br>> the purpose itself is lost, because at that point we would be taking a snap,<br>> making the limit<br>> hard-limit + 1, and then triggering auto-delete, which violates the sanctity<br>> of the hard-limit.<br>> Also what happens when we are at hard-limit + 1, and another snap is issued,<br>> while auto-delete<br>> is yet to process the first delete. At that point we end up at hard-limit +<br>> 1. Also what happens<br>> if for a particular snap the auto-delete fails.<br>> <br>> We should see the hard-limit, as something set by the admin keeping in mind<br>> the resource consumption<br>> and at no-point should we cross this limit, come what may. If we hit this<br>> limit, the create command<br>> should fail asking the user to delete snaps using the "snapshot delete"<br>> command.<br>> <br>> The two options Raghavendra mentioned are applicable for the soft-limit only,<br>> in which cases on<br>> hitting the soft-limit<br>> <br>> 1. Trigger auto-delete<br>> <br>> or<br>> <br>> 2. Log a warning-message, for the user saying the number of snaps is<br>> exceeding the snap-limit and<br>> display the number of available snaps<br>> <br>> Now which of these should happen also depends on the user, because the<br>> auto-delete option<br>> is configurable.<br>> <br>> So if the auto-delete option is set as true, auto-delete should be triggered<br>> and the above message<br>> should also be logged.<br>> <br>> But if the option is set as false, only the message should be logged.<br>> <br>> This is the behaviour as designed. Adding Rahul, and Seema in the mail, to<br>> reflect upon the<br>> behaviour as well.<br><div><br></div>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.<br><div><br></div>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.<br><div><br></div>Thanks,<br>Rahul<br><div><br></div>> <br>> Regards,<br>> Avra<br>> <br>> On 04/15/2014 07:18 PM, Lalatendu Mohanty wrote:<br>> <br>> > On 04/15/2014 07:05 PM, Raghavendra Bhat wrote:<br>> >><br>> >> Hi,<br>> >><br>> >> As of now, in snapshots there are 2 limits for the number of<br>> >> snapshots, hard-limit and soft-limit. Usually soft-limit is 90% of<br>> >> hard-limit by default (it can be changed also). Say the hard-limit is<br>> >> 50, then soft-limit by default will be 45. We are planning to do<br>> >> autodelete of the oldest snapshot upon reaching the limit.<br>> >><br>> >> There are 2 options:<br>> >><br>> >> 1) Start doing autodelete upon reaching the soft-limit. i.e If the<br>> >> hard limit is 50 and the number of the snapshots taken becomes 45,<br>> >> then for the next snapshot taken (i.e 46th snapshot), the oldest<br>> >> snapshot will be automatically deleted in the background.<br>> >><br>> >> 2) Use soft-limit as a means to notify the admin about limit being<br>> >> reached (gf_log, syslog etc, or also a warning message shown for<br>> >> every snapshot taken after the soft limit is reached) and start doing<br>> >> autodelete after reaching the hard-limit i.e once 50 snapshots are<br>> >> reached, then when 51st snapshot is triggered, the oldest snapshot<br>> >> will be deleted in the background.<br>> >><br>> >> Please provide feedback.<br>> ><br>> > I like the #2 option. If user has set something as hard-limit, it<br>> > should be treated as hard limit and soft-limit can be used as warning<br>> > mechanism.<br>> ><br>> >><br>> >> NOTE: The auto-delete can be made configurable, which if turned off,<br>> >> snapshot create fails upon reaching the limit.<br>> >><br>> >> Regards,<br>> >> Raghavendra Bhat<br>> >><br>> >> _______________________________________________<br>> >> Gluster-devel mailing list<br>> >> Gluster-devel@nongnu.org<br>> >> https://lists.nongnu.org/mailman/listinfo/gluster-devel<br>> ><br>> ><br>> > _______________________________________________<br>> > Gluster-devel mailing list<br>> > Gluster-devel@nongnu.org<br>> > https://lists.nongnu.org/mailman/listinfo/gluster-devel<br>> <br>> <br><div><br></div>_______________________________________________<br>Gluster-devel mailing list<br>Gluster-devel@nongnu.org<br>https://lists.nongnu.org/mailman/listinfo/gluster-devel<br></blockquote><div><br></div></div></body></html>