zfs discuss - Aug 2011 - zfs send and zfs destroy at the same time

What do you expect to happen if you''re in progress doing a zfs send,
and
then simultaneously do a zfs destroy of the snapshot you''re sending?

 

This happened to me today, because I''m replicating one server to
another...
So I''m sending the oldest snapshot first, to be followed by the
incrementals.  But the oldest one is of course the biggest one to send, so
it spanned the overnight midnight.  Meanwhile zfs-auto-snapshot tried to
destroy the oldest snap.

 

I''m now in a state where I can''t do "zfs list" and a
whole bunch of things
are failing...  I have 46 "zfs list" processes unkillabIe, and I have
28
zfs-auto-snapshot processes also unkillable.  I may be forced to reboot, and
I may have to start over.  If the destroy succeeds, then of course I
won''t
be able to use that snap as the initial point for the incrementals.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110828/18f39808/attachment.html>

On Aug 28, 2011, at 5:55 AM, Edward Ned Harvey wrote:
> What do you expect to happen if you''re in progress doing a zfs
send, and then simultaneously do a zfs destroy of the snapshot you''re
sending?
It depends on the release. For modern implementations, a hold is placed on the
snapshot and
it won''t be destroyed until the hold is removed.
>  
> This happened to me today, because I''m replicating one server to
another...  So I''m sending the oldest snapshot first, to be followed by
the incrementals.  But the oldest one is of course the biggest one to send, so
it spanned the overnight midnight.  Meanwhile zfs-auto-snapshot tried to destroy
the oldest snap.
>  
> I''m now in a state where I can''t do "zfs list"
and a whole bunch of things are failing...  I have 46 "zfs list"
processes unkillabIe, and I have 28 zfs-auto-snapshot processes also unkillable.
I may be forced to reboot, and I may have to start over.  If the destroy
succeeds, then of course I won''t be able to use that snap as the
initial point for the incrementals.
Sounds like a bug :-(
There are some large locks around some of these things...
 -- richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110828/86cfed6e/attachment.html>

> From: Richard Elling [mailto:richard.elling at gmail.com]
> 
>> What do you expect to happen if you''re in progress doing a zfs
send, and
>> then simultaneously do a zfs destroy of the snapshot you''re
sending?
> 
> It depends on the release. For modern implementations, a hold is placed on
> the snapshot and
> it won''t be destroyed until the hold is removed.
> 
> 
> 
>> This happened to me today, because I''m replicating one server
to
>> another...? So I''m sending the oldest snapshot first, to be
followed by
the
>> incrementals.? But the oldest one is of course the biggest one to send,
so it
>> spanned the overnight midnight. ?Meanwhile zfs-auto-snapshot tried to
>> destroy the oldest snap.
>>
>> I''m now in a state where I can''t do "zfs
list" and a whole bunch of
things are
>> failing...? I have 46 "zfs list" processes unkillabIe, and I
have 28
zfs-auto-
>> snapshot processes also unkillable.? I may be forced to reboot, and I
may
>> have to start over.? If the destroy succeeds, then of course I
won''t be
able to
>> use that snap as the initial point for the incrementals.
> 
> Sounds like a bug :-(
> There are some large locks around some of these things...
Sounds to me, like placing a "hold" on a snapshot has some unintended
side
effects...  Such as making a "zfs list" hang, just like the "zfs
destroy."
Perhaps that was intentional by design...  Ensuring commands complete in the
order they were run or something like that.  But I doubt it.  I bet
it''s a
bug.

In any event, I power cycled mine.