[LU-8207] Add auto-stripe option to lfs_migrate Created: 26/May/16 Updated: 03/Jan/20 Resolved: 03/Mar/19 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.7.0, Lustre 2.5.3 |
| Fix Version/s: | Lustre 2.13.0, Lustre 2.12.4 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Eric Schnepp | Assignee: | Nathaniel Clark |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | patch | ||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Rank (Obsolete): | 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": |
| Comments |
| Comment by Nathan Dauchy (Inactive) [ 26/May/16 ] |
|
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. |
| Comment by Joseph Gmitter (Inactive) [ 26/May/16 ] |
|
Hi Nathan, Can you please submit the patch through gerrit? Thanks. |
| Comment by Gerrit Updater [ 01/Jun/16 ] |
|
Nathan Dauchy (nathan.dauchy@nasa.gov) uploaded a new patch: http://review.whamcloud.com/20552 |
| Comment by Nathan Dauchy (Inactive) [ 01/Jun/16 ] |
|
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! |
| Comment by Nathan Dauchy (Inactive) [ 12/Oct/17 ] |
|
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! |
| Comment by Gerrit Updater [ 03/Mar/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/20552/ |
| Comment by Peter Jones [ 03/Mar/19 ] |
|
Landed for 2.13 |
| Comment by Gerrit Updater [ 09/Dec/19 ] |
|
Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36958 |
| Comment by Gerrit Updater [ 03/Jan/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36958/ |