denying an inherited zfs allow

[Paul B. Henson via illumos-zfs]

We are still trying to figure out the best way to deal with the interaction
between the replication system we are working on (which uses zfs holds to
mark which snapshots it is currently using), and our management application,
which would like to be able to delete zfs filesystems (which fails if there
are any held snapshots). While it is easy enough to enumerate and remove any
holds, currently there is the possibility that another one might be placed
after the existing ones were removed and before the file system is actually
deleted.

One suggestion my colleague made was to remove permissions from the
replication service account so it would not be able to place a hold on the
file system about to be deleted. However, unless I am misunderstanding zfs
management permissions, there is no way to deny a privilege on a filesystem
(say export/user/bob) that is allowed and inherited from a higher one (say
export)? So, unless we explicitly enumerated the permissions on each
individual filesystem rather than allow them to be inherited, I don't think
this approach would work.

Thanks.

[Timothy Coalson via illumos-zfs]

Some ideas not related to denying permissions to the replication job:

Can you tell the replication system to stop trying to replicate that
filesystem before you try to delete its target out from under it?

Alternatively, maybe doing a zfs rename (adding some prefix like
"deleting-", or making a random unused temporary name) before starting to
remove holds would make the replication system no longer able to find it,
so it wouldn't add new holds to it. I don't know how zfs rename interacts
with holds and in-progress receives, but I would expect it to act sensibly.

Yet uglier, maybe if the first pass fails, take a second pass at removing
all holds/snapshots (on what should now be substantially fewer snapshots,
if you remove each snapshot immediately after removing its holds), which
may be less likely to fail.

Tim



On Thu, Aug 14, 2014 at 3:48 PM, Paul B. Henson via illumos-zfs <

Post by Paul B. Henson via illumos-zfs
We are still trying to figure out the best way to deal with the interaction
between the replication system we are working on (which uses zfs holds to
mark which snapshots it is currently using), and our management application,
which would like to be able to delete zfs filesystems (which fails if there
are any held snapshots). While it is easy enough to enumerate and remove any
holds, currently there is the possibility that another one might be placed
after the existing ones were removed and before the file system is actually
deleted.
One suggestion my colleague made was to remove permissions from the
replication service account so it would not be able to place a hold on the
file system about to be deleted. However, unless I am misunderstanding zfs
management permissions, there is no way to deny a privilege on a filesystem
(say export/user/bob) that is allowed and inherited from a higher one (say
export)? So, unless we explicitly enumerated the permissions on each
individual filesystem rather than allow them to be inherited, I don't think
this approach would work.
Thanks.
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
https://www.listbox.com/member/archive/rss/182191/24077749-f7a4e87a
https://www.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com

[Paul B. Henson via illumos-zfs]

From: Timothy Coalson
Sent: Thursday, August 14, 2014 2:20 PM
Can you tell the replication system to stop trying to replicate that filesystem
before you try to delete its target out from under it?

We are doing a recursive replication from the top of the pool, so there's really no way to single out individual subsidiary filesystems to skip.

Alternatively, maybe doing a zfs rename (adding some prefix like "deleting-",
or making a random unused temporary name) before starting to remove
holds would make the replication system no longer able to find it, so it
wouldn't add new holds to it. I don't know how zfs rename interacts with
holds and in-progress receives, but I would expect it to act sensibly.

Again, no go for a recursive replication.

Yet uglier, maybe if the first pass fails, take a second pass at removing all
holds/snapshots (on what should now be substantially fewer snapshots, if
you remove each snapshot immediately after removing its holds), which may
be less likely to fail.

We weren't planning on removing snapshots individually, just doing a destroy -r on the filesystem itself once the holds were removed. I suppose we could try removing individual snapshots, but I think that would be much less efficient, particularly if there might be a lot of them.

It seems there should just really be a clean way to delete a file system and all its snapshots even in the face of holds. I took a brief look at what it might take to modify the -f flag to force a delete and override holds, but that flag only exists in user space and the actual deletion is done via an ioctl to kernel space, and it seems like would be very complicated to try and do things differently.

Right now we are tentatively thinking of instead of replicating from the top, replicating from one level down, and then creating a new directory at the top level to hold things pending deletion to get them out of the way of the replication engine.

Thanks…

[Simon Casady via illumos-zfs]

I don't understand your use of holds. If you are proposing deleting a file
system that the replication process is trying to replicate then why have
holds in the first place ?


On Mon, Aug 18, 2014 at 6:18 PM, Paul B. Henson via illumos-zfs <

Post by Paul B. Henson via illumos-zfs

From: Timothy Coalson
Sent: Thursday, August 14, 2014 2:20 PM
Can you tell the replication system to stop trying to replicate that

filesystem

before you try to delete its target out from under it?

We are doing a recursive replication from the top of the pool, so there's
really no way to single out individual subsidiary filesystems to skip.

Alternatively, maybe doing a zfs rename (adding some prefix like

"deleting-",

or making a random unused temporary name) before starting to remove
holds would make the replication system no longer able to find it, so it
wouldn't add new holds to it. I don't know how zfs rename interacts with
holds and in-progress receives, but I would expect it to act sensibly.

Again, no go for a recursive replication.

Yet uglier, maybe if the first pass fails, take a second pass at

removing all

holds/snapshots (on what should now be substantially fewer snapshots, if
you remove each snapshot immediately after removing its holds), which may
be less likely to fail.

We weren't planning on removing snapshots individually, just doing a
destroy -r on the filesystem itself once the holds were removed. I suppose
we could try removing individual snapshots, but I think that would be much
less efficient, particularly if there might be a lot of them.
It seems there should just really be a clean way to delete a file system
and all its snapshots even in the face of holds. I took a brief look at
what it might take to modify the -f flag to force a delete and override
holds, but that flag only exists in user space and the actual deletion is
done via an ioctl to kernel space, and it seems like would be very
complicated to try and do things differently.
Right now we are tentatively thinking of instead of replicating from the
top, replicating from one level down, and then creating a new directory at
the top level to hold things pending deletion to get them out of the way of
the replication engine.
Thanks

-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
https://www.listbox.com/member/archive/rss/182191/24018577-4d8b86e0
https://www.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com

[Paul B. Henson via illumos-zfs]

From: Simon Casady
Sent: Tuesday, August 19, 2014 5:51 AM
I don't understand your use of holds. If you are proposing deleting a file
system that the replication process is trying to replicate then why have holds
in the first place ?

Basically we are providing webspace to users and groups. There is one component that is in charge of replicating from the master server to a failover that would continue to serve the pages if the primary storage server was down, and another management component that is in charge of provisioning and de-provisioning storage for users and groups. The conflict is that the replication component might have holds on snapshots for the purposes of replicating a particular filesystem when the management component comes along and wants to deprovision it. My preference was to simply allow the management component to destroy the file system regardless of holds, but as that is not currently possible we ended up having to have the management component just flag the file system for destruction and the replication component actually do the destroy call.