On 01/08/09 06:39, Tim Foster wrote:
hi Rich,
On Wed, 2009-01-07 at 10:51 -0500, Richard Morris - Sun Microsystems -
Burlington United States wrote:
As you point out, the -c option is user friendly while the -depth (or
maybe -d) option is more general. There have been several requests for
the -c option. Would anyone prefer the -depth option? In what cases
would this be used?
I was thinking when I logged the bug, that -depth (or -d) would be
useful in cases where you've got a "jurassic-like" filesystem layout,
and are interested in seeing just one or two levels.
zfs list -d 3 tank
tank/home
tank/home/Ireland
tank/home/UK
tank/home/France
tank/home/Germany
tank/foo
tank/foo/bar
allowing you to look at just the level of hierarchy that you're
interested in (eg. "How much disk space are users from different
countries taking up taking up?"), without needing to grep, or hardcode
a list of datasets somewhere.
More importantly, with hopefully faster performance than showing
all children of tank/home just to get the size of the immediate children.
Hi Tim,
Both the -c and -d options would eliminate the need to grep or hardcode
a list of datasets. And they would both improve zfs list performance by
eliminating unnecessary recursion. So adding one of these options probably
makes sense. But which one? Is the added complexity of the -d option over
the -c option justified? In the above example, wouldn't the question "how
much disk space per country" also be answered by zfs list -c /tank/home?
Perhaps a layout like this might be a better argument for the -d option?
tank/america/Canada
tank/america/Mexico
tank/america/USA
tank/europe/France
tank/europe/Germany
tank/europe/Ireland
But how often would the -d option be provided a value other than 1 or 2?
As a point of reference, the ls command also has this issue and does not
provide an option to limit the depth of recursion. And ls has no shortage
of options (aAbcCdeEfFghHilLmnopqrRstuvVx1@)! Of course, this does not
necessarily mean that the -d option would not be useful for zfs list.
Other opinions?
-- Rich
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
