> From: Richard Elling [mailto:richard.ell...@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. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss