[LU-8314] user interface of lfs getdirstripe needs reworking

Related — Thu, 10 Aug 2017 23:42:00 +0000

lfs's subcommand "getdirstripe" has a very strange, and user unfriendly interface. For whatever reason, getdirstripe always recurses one level down.

Here is an example directory tree on Lustre 2.8.0:

$ find level1
level1
level1/level2_c
level1/level2_b
level1/level2_a
level1/level2_a/level3_c
level1/level2_a/level3_b
level1/level2_a/level3_a

If I just want to get the directory striping information for the directory named "level1", I might assume that the command is "lfs getdirstripe level1". But this is what I get instead:

$ lfs getdirstripe level1
level1
lmv_stripe_count: 0 lmv_stripe_offset: 0
level1/level2_c
lmv_stripe_count: 0 lmv_stripe_offset: 0
level1/level2_b
lmv_stripe_count: 0 lmv_stripe_offset: 0
level1/level2_a
lmv_stripe_count: 0 lmv_stripe_offset: 0

Not only did it give me the information for the directory that I actually asked for, it also decided to recurse on level down the tree and give me the directory information for all subdirectories.

The man page more-or-less acknowledges this behaviour, but it buries the detail in the -r/--recursive option. So I can only assume that this was intentional rather than an accidental off-by-one default recursion count in the code.

-r, --recursive
The default behavior when a directory is specified is to list the striping information
for all sub-directories within the specified directory. This can be expanded with
--recursive, which will recurse into all subdirectories.

The information there isn't exactly accurate either, because it actually lists the information for the specified directory and all of its sub-directories, not just the sub-directories of the specified directory.

But the documentation is not really the problem. The problem is that this is a bad user interface.

When a user types "lfs getdirstripe somedirectory", by default it should print the information for directory "somedirectory" and nothing else. Preferably it will not print "somedirectory" again in response before showing somedirectory's directory striping information. Just print the dir striping information and nothing else.

Just to make it super clear, here is an example of something more like I would expect to see from this command:

$ lfs getdirstripe level1
lmv_stripe_count: 0 lmv_stripe_offset: 0

That is it. Nothing else.

This would make the command consistent with the -c and -i options as well. This is how those currently work:

$ lfs getdirstripe -c level1
0
$ lfs getdirstripe -i level1
0

For those commands it didn't decide to also show the requested information for all of the subdirectories as well.

And while we are on the topic of weird interfaces, what the heck is this supposed to mean:

-q, --quiet
Only show the details of the sub-striped directory FID information.

I have absolutely no idea. Apparently it turns of all output:

$ lfs getdirstripe -q level1

That seems overly quiet. But then, I don't understand what "details of the sub-striped directory FID information", so I can't tell if printing nothing makes any sense.

And next we have the verbose option with which supposedly "Additional information will be shown". But no additional information is shown:

$ lfs getdirstripe -v level1
level1
lmv_stripe_count: 0 lmv_stripe_offset: 0
level1/level2_c
lmv_stripe_count: 0 lmv_stripe_offset: 0
level1/level2_b
lmv_stripe_count: 0 lmv_stripe_offset: 0
level1/level2_a
lmv_stripe_count: 0 lmv_stripe_offset: 0

Maybe there is some other situation under which it would print more information?

Overall, the lfs getdirstripe command needs work before we can turn it over to our users.

Whamcloud Community JIRA

[LU-8314] user interface of lfs getdirstripe needs reworking