Details
-
Bug
-
Resolution: Fixed
-
Critical
-
Lustre 2.8.0
-
3
-
9223372036854775807
Description
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.
Attachments
Activity
Labels | Original: llnl topllnl | New: llnl |
Link | Original: This issue is related to JFC-24 [ JFC-24 ] |
Link | Original: This issue is related to LDEV-341 [ LDEV-341 ] |
Link | Original: This issue is related to JFC-17 [ JFC-17 ] |
Link | New: This issue is related to LDEV-342 [ LDEV-342 ] |
Link | New: This issue is related to JFC-20 [ JFC-20 ] |
Fix Version/s | New: Lustre 2.10.0 [ 12204 ] |
Link | New: This issue is related to JFC-24 [ JFC-24 ] |
Link | New: This issue is related to JFC-17 [ JFC-17 ] |
Link | Original: This issue is related to JFC-10 [ JFC-10 ] |