[LU-9162] Option to set max stripe count per filesystem Created: 27/Feb/17 Updated: 10/Mar/23 Resolved: 30/Nov/21 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.7.0 |
| Fix Version/s: | Lustre 2.15.0 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Mahmoud Hanafi | Assignee: | Feng Lei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | easy | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||||||||||
| Description |
|
We have users that will set stripe count by using "-1" as in Filesystem with small number of OSTs (~200) this was ok. But as our OST count get lager (>400) this is not always desirable. Most of the time we don't want our users to set stripe counts so large. We would like config option for max default size setting for (lfs setstripe -c -1). But would still like the ability to allow setting stripe counts upto LOV_MAX_STRIPE_COUNT for those who really need it. |
| Comments |
| Comment by Peter Jones [ 27/Feb/17 ] |
|
Mahmoud Is this something that you are working on or more of a suggestion for an enhancement? We discussed this a little on the daily engineering call and the feeling was that this could be a useful change though there would still need to be some consideration given to be able to override this behaviour. Peter |
| Comment by Mahmoud Hanafi [ 21/Mar/17 ] |
|
Peter, |
| Comment by Andreas Dilger [ 19/Oct/17 ] |
|
Mahmoud, I just noticed this ticket when searching for another issue. It looks like this would be relatively straight forward to do. It looks like what would be needed is to add a /proc tunable to specify e.g. maximum_stripe_count (0 if no limit), and add another check into lod_get_stripe_count(), something like:
if (stripe_count > lod->lod_desc.ld_active_tgt_count) {
if (lod->lod_max_stripe_count &&
lod->lod_max_stripe_count < lod->lod_desc.ld_active_tgt_count)
stripe_count = lod->lod_max_stripe_count;
else
stripe_count = lod->lod_desc.ld_active_tgt_count;
}
|
| Comment by Feng Lei [ 15/Oct/21 ] |
|
lod_desc is origially a readonly struct so there is no lock protection on it. If we add a changable field ld_max_stripe_count into it, we need a lock to protect it anywhere it's accessed. Is it too expensive? |
| Comment by Feng Lei [ 15/Oct/21 ] |
|
one more question is where to put the lock? |
| Comment by Andreas Dilger [ 16/Oct/21 ] |
|
flei, I don't think this needs locking, because it is "racy" even with a lock. The value could be accessed a microsecond before or after the value is changed by the user, so having a lock won't help that. It will only affect the one file being created at the time it is checked, and does not really need to be consistent from one file to the next. Also, this does not really need to be part of lov_desc, which was the old/original way to set the default "plain" layout of the filesystem, but has been deprecated with the introduction of more complex PFL/FLR layouts. It would be better to make this a normal sysfs tunable that can be set with "lctl set_param [-P] lod.*.max_stripe_count". |
| Comment by Feng Lei [ 10/Nov/21 ] |
|
Is is OK to make the max_stripe_count a member of lod_device? |
| Comment by Andreas Dilger [ 10/Nov/21 ] |
|
Yes, definitely. You can copy stripeoffset_show() and stripeoffset_store() to print/store the parameter in lod_device. |
| Comment by Gerrit Updater [ 11/Nov/21 ] |
|
"Feng, Lei <flei@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/45532 |
| Comment by Gerrit Updater [ 30/Nov/21 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/45532/ |
| Comment by Peter Jones [ 30/Nov/21 ] |
|
Landed for 2.15 |