[LU-15276] DNE3: "lfs find" able to check default directory and file layout Created: 25/Nov/21  Updated: 31/Jan/22

Status: Open
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Andreas Dilger Assignee: WC Triage
Resolution: Unresolved Votes: 0
Labels: medium

Issue Links:
Related
is related to LU-5170 lfs usability Open
is related to LU-7501 inconsistencies between "lfs find", "... Resolved
is related to LU-15504 "lfs find" is missing "-ls" support Open
is related to LU-7495 lfs find is missing "-links" support Resolved
is related to LU-7502 add lfs find --mdt-count and --mdt-ha... Resolved
is related to LU-10378 "lfs find" is missing "-printf" support Resolved
Rank (Obsolete): 9223372036854775807

 Description   

It would be useful for "lfs find" to be able to check directories for the default file or directory layout, so that it is possible to scan a filesystem for directories that have explicit default layouts, like:

client# lfs find /mnt/testfs -type d --default --mdt-count +1 -print0 | xargs -0 lfs setdirstripe --delete
client# lfs find /mnt/testfs -type d --default -m 2 -print0 | xargs -0 lfs setdirstripe --delete

Unfortunately, "-D" is already used by "lfs find" as the short option for --maxdepth. Note also that the "--delete|-d" option is not listed in the "lfs setdirstripe" usage message and should be added. At least it is already in the lfs-setdirstripe.1 man page.

I like the idea of using the same --default long option name as "lfs setdirstripe" has, but to be able to distinguish searching for default file layouts from default directory layouts, do we need to have separate "--mdt-default" and "--ost-default" options? For the long options it is unambiguous what is intended, but the -c and -i short options overlap between "lfs setstripe" and "lfs setdirstripe". However, "lfs find" can already use -m instead of -i, and similarly -T can be used instead of -c, so I don't think there is a problem.


Generated at Sat Feb 10 03:16:56 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.