Make ZFS auto-destroy snapshots when the out of space?

jhell jhell at
Mon May 31 02:27:24 UTC 2010

On 05/30/2010 18:06, Kirk Strauser wrote:
> On May 29, 2010, at 9:42 PM, Dan Nelson wrote:
>> If the kernel does the snapshot deleting itself, why not add a pool-level
>> property that sets the amount of free space at which the deletion starts?
>> That way you don't need the cleanup script.  Alternatively, make the
>> org.freebsd:allowautodestroy property hold the trigger freespace amount.
>> That way you can have monthly/daily/hourly snapshots but set it so the
>> hourly ones disappear first, then the dailies (by setting the destroy
>> trigger slightly higher for the ones you want to expire first).
> That'd definitely work. The idea was to keep as much as possible out of
> the kernel so that it wouldn't add additional complexity for people who
> don't use it (but it certainly wouldn't offend me any to find it in
> there :-) ).

I think this would probably be best handled by the script that is
creating the snapshots. Though this is a nice feature how well would it
be received upstream and in what period of time would we have to wait
while maintaining are down-level patches.

I would propose looking at the creation time of the snapshots while in
creation mode and parsing for a time that is older than a use
configurable variable so the script can take proper action when
destroying snapshots before it tries to create a new one and look at a
value comprised of either the quota property or a attribute like the
previous one stated.

I strongly urge against creating a attribute that the script would look
for due to the reason it would take more involvement with the script to
be specific to FreeBSD where as now it should be OS independent.

# This works good enough to compare with date(1) "+%s"
zfs get -o name,value creation | grep @

# This works for seeing exactly how much a snapshot is using
zfs get -o name,value used |grep @

Between the above two examples a threshold can be achieved at which
older data can expire faster or slower depending on your settings and
provide an upper tolerance for space usage.

Of course this can be refined and there is a whole lot that is left to
be scripted around the above commands.





More information about the freebsd-stable mailing list