On Mar 29, 2012, at 5:11 PM, Richard Elling wrote:
>> Thank you very much Ian and Carsten. Well, adding a -v gave me a clue. Turns
>> out that one of the old snapshots had a clone created.
>> zfs receive -v was complaining that it couldn't destroy an old snapshot,
>> which wasn't visible but had been cloned (and forgotten) long ago. A truss
>> of the zfs receive process shown it accessing the clone.
>> So, zfs receive was doing its job, the new snapshot was applied correctly,
>> but it was exiting with an exit value of 1, without printing any warnings,
>> which I think is wrong.
> You are correct. Both zfs and zpool have a bad case of "exit 1 if something
> isn't right."
> At Nexenta, I filed a bug against the ambiguity of the return code. You
> should consider
> filing a similar bug with Oracle. In the open-source ZFS implementations,
> there is some
> other work to get out of the way before properly tackling this, but that work
> is in progress :-)
I understand that either a warning or, at least, a syslog message with
LOG_WARNING is in order.
Regarding the open source camp, yes, I'm using ZFS on FreeBSD as well :)
zfs-discuss mailing list