Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
Lustre 2.7.0, Lustre 2.5.3
-
9223372036854775807
Description
The primary reason for this feature is to be able to give users a tool to fix stripe settings on existing files based on file size. Optimal stripe selection for performance is dependent on access patern, but we can make the assumption that large files are more likely to be accessed by multiple clients and benefit from wider striping. The other benefit from restriping is to balance OST capacity used, which an algorithm based solely on file size can more easily address.
The goal is to have a tool to give the users and say "go restripe your directory with this command" and it will do the right thing in 90% of cases. lfs_migrate already has most of the needed functionality. The change would be to add a "-A" flag to automatically select the stripe count as the file is rewritten. Initial algorithm to determine stripe count is Log2(size_in_GB)+1, though this could change in the future.
The other application of this patch would be to integrate it with Robinhood (or "lfs find") to generate a list of large, inactive, and narrowly-striped files and pass them to lfs_migrate for restriping. This could be coupled well with OST rebalancing actions.
For further discussion and context, see mailing list thread "stripe count recommendation, and proposal for auto-stripe tool":
http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/2016-May/013526.html
Attachments
Issue Links
Activity
Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36958
Subject: LU-8207 scripts: add auto-stripe option to lfs_migrate
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: 70db4d54052c47b2d77641ed26464aabd26efccb
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/20552/
Subject: LU-8207 scripts: add auto-stripe option to lfs_migrate
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 99d7a8ed43be126b2769ad8bb0b5350cd328ed7f
FYI, colleagues at NASA pointed out that the log function curved the wrong way. "sqrt($SIZE_IN_GB)" would probably be a better fit for the initial auto stripe algorithm.
Sorry I haven't had time to work on this. Thanks to Steve G. for picking it up!
Patch updated to try to incorporate comments from the lustre-discuss thread, and submitted to gerrit.
This is my first submitted patch, so I hope I put it into the system correctly! 
Nathan Dauchy (nathan.dauchy@nasa.gov) uploaded a new patch: http://review.whamcloud.com/20552
Subject: LU-8207 scripts: add auto-stripe option to lfs_migrate
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 5b445117677d684f3782d1f7f30ed31eba87c4bd
Hi Nathan,
Can you please submit the patch through gerrit?
Thanks.
Joe
Draft patch attached, lightly tested, still needs work. It also includes a useful "-v" option to increase verbosity and help test/debug/monitor what is being done.
This should be updated to use pure bash instead of 'bc' for the log function. Use a simple "multiply by 2, increment stripe_count, compare to file size" loop, after converting bytes to GiB? That would be a few cycles for huge files, but probably still faster than fork/exec of an external binary.
May also want to include a case to switch to stripe_count=(file_size)/100GB for very large files to cap the capacity used on each OST. And the 150GB value could itself be dynamic, and instead calculated as a percentage (1%? 5%?) of the capacity of the smallest OST. This would prevent any single file from taking up too much space on a target.
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36958/
Subject:
LU-8207scripts: add auto-stripe option to lfs_migrateProject: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: f1edda04ac6821ffa2c1e9be01437a55852df4cf