destroying filesystems with held snapshots

[Paul B. Henson via illumos-zfs]

Given a file system potentially with some number of snapshots, each of which
potentially with some number of holds, is there any easy way to destroy it
without having to explicitly enumerate each snapshot, look for holds on it,
and individually release those holds? I was kind of hoping -f would brute
force through it, but no go.

Thanks.

[Matthew Ahrens via illumos-zfs]

No, I don't think so. You should be able to write a script to do
this. If you do so, maybe you could share it with the group in case
someone else has the need to blow away all snapshot holds.

--matt

Post by Paul B. Henson via illumos-zfs
Given a file system potentially with some number of snapshots, each of which
potentially with some number of holds, is there any easy way to destroy it
without having to explicitly enumerate each snapshot, look for holds on it,
and individually release those holds? I was kind of hoping -f would brute
force through it, but no go.
Thanks.
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
https://www.listbox.com/member/archive/rss/182191/21635000-ebd1d460
https://www.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

[Paul B. Henson via illumos-zfs]

Post by Matthew Ahrens via illumos-zfs
No, I don't think so. You should be able to write a script to do
this. If you do so, maybe you could share it with the group in case
someone else has the need to blow away all snapshot holds.

It's not that difficult necessarily to find them and clean them up, one
of the guys I work with came up with this one liner:

zfs list -r -t snapshot -H -d 1 -o name <filesystem> | xargs
zfs holds -H | awk '{print $2, $1}' | xargs -n 2 zfs release

It just would be nice to have an option to force the deletion of
something with holds so you didn't have to. We also have an issue where
the replication system we're building might sneak in and add another
hold while we're cleaning up the holds that were already there and cause
the destroy to still fail. So instead of a simple "delete that no matter
what", we're going to need to have a more complicated mechanism to
handle existing holds and possible race conditions between holds being
created and filesystems being destroyed.

Thanks...