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 :) Borja. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
