[LU-9162] Option to set max stripe count per filesystem

• Type: New Feature
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.15.0
• Affects Version/s: Lustre 2.7.0
• Labels: easy
• Assignee: Feng Lei
• Reporter: Mahmoud Hanafi

Description

We have users that will set stripe count by using "-1" as in
lfs setstripe -c -1

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.

Issue Links

• is cloned by: LU-15307 Option to set max directory stripe count per filesystem
• is related to: LU-13748 'lfs setstripe -C -1' stripes too widely
• is related to: LU-6689 Requesting a tunable that prevents regular users from setting the initial OST
• is related to: LUDOC-501 Document (dir)stripe limits

Comments

[Peter Jones]

Landed for 2.15

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/45532/
Subject: LU-9162 lod: option to set max stripe count per filesystem
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 3c9580931d1a7753e6c03900df01fd05ab3ca73d

[Gerrit Updater]

"Feng, Lei <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/45532
Subject: LU-9162 lod: option to set max stripe count per filesystem
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 80534f98629dedaeb381757e97f8c9d7bf62ac0c

[Andreas Dilger]

Yes, definitely. You can copy stripeoffset_show() and stripeoffset_store() to print/store the parameter in lod_device.

[Feng Lei]

Is is OK to make the max_stripe_count a member of lod_device?

[Andreas Dilger]

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".

[Feng Lei]

one more question is where to put the lock?

[Feng Lei]

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?

[Andreas Dilger]

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;
        }

[Mahmoud Hanafi]

Peter,
This is an area we can do the development but we would like some guidance about how the config option should be stored.