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

Reply via email to