Evan Layton wrote:
> Ethan Quach wrote:
>>
>>
>> Evan Layton wrote:
>>> Ethan Quach wrote:
>>>>
>>>>
>>>> Evan Layton wrote:
>>>>> jeanm wrote:
>>>>>> Looks OK to me. Maybe some comments explaining the B_FALSE and
>>>>>> what it does?
>>>>>> I looked in the zfs code but that's kind of awkward.
>>>>>
>>>>> Probably a good idea to add that since it's a bit convoluted...
>>>>>
>>>>> I've added:
>>>>> /*
>>>>> * The boolean set to B_FALSE and passed to zfs_destroy_snaps() tells
>>>>> * zfs to process and destroy the snapshots now. Otherwise ZFS will
>>>>> * wait to destroy these snapshots until a zfs release is called and
>>>>> * the references for all the snapshots have been released.
>>>>> */
>>>>
>>>> nit - for the second sentence, "Otherwise the call will potentially
>>>> return where the snapshot isn't actually destroyed yet, and ZFS is
>>>> waiting until all the references to the snapshot have been released
>>>> before actually destroying the snapshot."
>>>>
>>>
>>> Much better! I'll make that change.
>>
>> Hmm, I may have made an incorrect assumption on the behavior
>> though. Will the call actually return and ZFS waits, or wait before
>> returning?
>
> If I understand the comments and the code correctly, ZFS returns without
> actually destroying the snapshots. It waits to do that until all the
> references are released and the zfs_release has been called.
Devil's advocate: What's the problem with using B_TRUE if this is how it
works? If someone has truly set a hold on a BE snapshot, it seems more
appropriate to let ZFS clean it up later when whoever put the hold on it
is done with it. As long as it gets cleaned up eventually &
automatically... And if we don't want people putting holds on it, would
it be more appropriate to set the ZFS property such that normal users
can't put a hold on it?
