Hmm... that's a tough one. To me, it's a trade off either way, using a -r parameter to specify the depth for zfs list feels more intuitive than adding extra commands to modify the -r behaviour, but I can see your point.
But then, using -c or -d means there's an optional parameter for zfs list that you don't have in the other commands anyway. And would you have to use -c or -d with -r, or would they work on their own, providing two ways to achieve very similar functionality. Also, now you've mentioned that you want to keep things consistent among all the commands, keeping -c and -d free becomes more important to me. You don't know if you might want to use these for another command later on. It sounds to me that whichever way you implement it there's going to be some potential for confusion, but personally I'd stick with using -r. It leaves you with a single syntax for viewing children. The -r on the other commands can be modified to give an error message if they don't support this extra parameter, and it leaves both -c and -d free to use later on. Ross On Fri, Jan 9, 2009 at 7:16 PM, Richard Morris - Sun Microsystems - Burlington United States <richard.mor...@sun.com> wrote: > On 01/09/09 01:44, Ross wrote: >> >> Can I ask why we need to use -c or -d at all? We already have -r to >> recursively list children, can't we add an optional depth parameter to that? >> >> You then have: >> zfs list : shows current level (essentially -r 0) >> zfs list -r : shows all levels (infinite recursion) >> zfs list -r 2 : shows 2 levels of children > > An optional depth argument to -r has already been suggested: > http://mail.opensolaris.org/pipermail/zfs-discuss/2009-January/054241.html > > However, other zfs subcommands such as destroy, get, rename, and snapshot > also provide -r options without optional depth arguments. And its probably > good to keep the zfs subcommand option syntax consistent. On the other > hand, > if all of the zfs subcommands were modified to accept an optional depth > argument > to -r, then this would not be an issue. But, for example, the top level(s) > of > datasets cannot be destroyed if that would leave orphaned datasets. > > BTW, when no dataset is specified, zfs list is the same as zfs list -r > (infinite > recursion). When a dataset is specified then it shows only the current > level. > > Does anyone have any non-theoretical situations where a depth option other > than > 1 or 2 would be used? Are scripts being used to work around this problem? > > -- Rich > > > > > > > > > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
