Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-9162

Option to set max stripe count per filesystem

Details

    • New Feature
    • Resolution: Fixed
    • Major
    • Lustre 2.15.0
    • Lustre 2.7.0
    • 9223372036854775807

    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.

      Attachments

        Issue Links

          Activity

            [LU-9162] Option to set max stripe count per filesystem
            flei Feng Lei added a comment -

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

            flei Feng Lei added a comment - Is is OK to make the max_stripe_count a member of lod_device?

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

            adilger Andreas Dilger added a comment - 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 ".
            flei Feng Lei added a comment -

            one more question is where to put the lock?

            flei Feng Lei added a comment - one more question is where to put the lock?
            flei Feng Lei added a comment -

            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?

            flei Feng Lei added a comment - 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?
            adilger Andreas Dilger added a comment - - edited

            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;
                    }
            
            adilger Andreas Dilger added a comment - - edited 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; }

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

            mhanafi Mahmoud Hanafi added a comment - Peter, This is an area we can do the development but we would like some guidance about how the config option should be stored.
            pjones Peter Jones added a comment -

            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

            pjones Peter Jones added a comment - 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

            People

              flei Feng Lei
              mhanafi Mahmoud Hanafi
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: