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

store default filesystem layout directly on root inode

Details

    • New Feature
    • Resolution: Fixed
    • Minor
    • Lustre 2.9.0
    • None
    • 9223372036854775807

    Description

      The use of lov_desc to store the default filesystem layout is restrictive as new layout types are added, and prevents functionality such as using "lfs setstripe" to set a default pool for the filesystem.

      The default layout xattr should actually be stored directly on the filesystem root inode, instead of just virtually using that as meaning "store the default layout into lov_desc". That would avoid any feature problems as new layout types are added in the future, since it will just be storing a layout xattr.

      Attachments

        Issue Links

          Activity

            [LU-7335] store default filesystem layout directly on root inode

            This was fixed as part of patch http://review.whamcloud.com/20348 "LU-7660 dne: support fs default stripe" and patch http://review.whamcloud.com/20849 "LU-8264 lod: lfs setstripe fix for pool".

            adilger Andreas Dilger added a comment - This was fixed as part of patch http://review.whamcloud.com/20348 " LU-7660 dne: support fs default stripe" and patch http://review.whamcloud.com/20849 " LU-8264 lod: lfs setstripe fix for pool".

            Lai, can you please verify that this issue is fixed with your patch http://review.whamcloud.com/19041 "LU-7660 dne: support fs default stripe" and then close this ticket if it is. Otherwise, please add a comment explaining what still needs to be done.

            If closing, please add "Fix Version: 2.9.0" for all of these tickets also.

            adilger Andreas Dilger added a comment - Lai, can you please verify that this issue is fixed with your patch http://review.whamcloud.com/19041 " LU-7660 dne: support fs default stripe" and then close this ticket if it is. Otherwise, please add a comment explaining what still needs to be done. If closing, please add "Fix Version: 2.9.0" for all of these tickets also.

            There are multiple methods to set the default layout parameters for the filesystem. The --param lov.stripecount=4 option can be used at format time to specify the initial value for the filesystem. This is equivalent to using lctl conf_param $fsname.lov.stripecount=4 after the filesystem has been formatted. Later on, the ability to set the striping parameters via lfs setstripe -c 4 /mnt/lustre was added to make it more consistent with the ability to set the default striping parameters on a parent directory. I think it makes sense to only allow the lfs setstripe [opts, ...] /mnt/lustre interface for storing more complex default layouts, but continue to allow the "conf_param" options for setting basic options like stripe_size.

            My understanding is that the question you asked is what should be done with PFL for specifying the default stripe parameters for components within the file? I think they should use defaults for simple parameters (e.g. stripe size), otherwise it would only be able to set the filesystem-wide default PFL layout once, and then not have any place to get defaults when creating non-PFL files. I don't like the idea of only having compiled-in defaults for new plain file layouts.

            adilger Andreas Dilger added a comment - There are multiple methods to set the default layout parameters for the filesystem. The --param lov.stripecount=4 option can be used at format time to specify the initial value for the filesystem. This is equivalent to using lctl conf_param $fsname.lov.stripecount=4 after the filesystem has been formatted. Later on, the ability to set the striping parameters via lfs setstripe -c 4 /mnt/lustre was added to make it more consistent with the ability to set the default striping parameters on a parent directory. I think it makes sense to only allow the lfs setstripe [opts, ...] /mnt/lustre interface for storing more complex default layouts, but continue to allow the "conf_param" options for setting basic options like stripe_size. My understanding is that the question you asked is what should be done with PFL for specifying the default stripe parameters for components within the file? I think they should use defaults for simple parameters (e.g. stripe size), otherwise it would only be able to set the filesystem-wide default PFL layout once, and then not have any place to get defaults when creating non-PFL files. I don't like the idea of only having compiled-in defaults for new plain file layouts.

            I'm afraid that keeping these default values will confusing users since there will be two interfaces to set the system default layout.

            My proposal is to remove the old default values in config log but use the root LOVEA instead: If the LOVEA of root is a v1/v3, then get the default stripe_size/count/offset from the v1/v3 like what we do today; If no default setting in root LOVEA, use the hard code initial values (same as today's behavior); If it's a composite in root LOVEA, get the stripe_size/count/offset from the first component (this is the only difference with today's behavior);

            That way we can save one additional interface/operation for users. I think "tuning default xxx value" sounds somewhat redundant, I don't think default (initial) value should be tuneable (it should be a hard coded instead), if user don't want default value, he can just tune the value directly (specify the stripe_offset/count/size directly) but not to specify a different default value. What do you think?

            niu Niu Yawei (Inactive) added a comment - I'm afraid that keeping these default values will confusing users since there will be two interfaces to set the system default layout. My proposal is to remove the old default values in config log but use the root LOVEA instead: If the LOVEA of root is a v1/v3, then get the default stripe_size/count/offset from the v1/v3 like what we do today; If no default setting in root LOVEA, use the hard code initial values (same as today's behavior); If it's a composite in root LOVEA, get the stripe_size/count/offset from the first component (this is the only difference with today's behavior); That way we can save one additional interface/operation for users. I think "tuning default xxx value" sounds somewhat redundant, I don't think default (initial) value should be tuneable (it should be a hard coded instead), if user don't want default value, he can just tune the value directly (specify the stripe_offset/count/size directly) but not to specify a different default value. What do you think?

            You are right - it does make sense to keep the default values for a single layout component. I hadn't thought of that. I don't think we should hard code these defaults, since we already have the ability to set them in lov_desc.

            adilger Andreas Dilger added a comment - You are right - it does make sense to keep the default values for a single layout component. I hadn't thought of that. I don't think we should hard code these defaults, since we already have the ability to set them in lov_desc.
            bobijam Zhenyu Xu added a comment -

            Or we can hard code in the default stripe_size/count/offset value, and get rid of lov_desc stripe members. And root inode's layout are only for layout inheritance.

            bobijam Zhenyu Xu added a comment - Or we can hard code in the default stripe_size/count/offset value, and get rid of lov_desc stripe members. And root inode's layout are only for layout inheritance.
            bobijam Zhenyu Xu added a comment -

            I think the default filesystem stripe_size/count/offset in lov_desc is still useful. When user assigned a default stripe_size/count/offset value for a layout component, it can still use the corresponding filesystem default value, otherwise user would has to explicitly specify stripe_size/count/offset values for all layout components.

            bobijam Zhenyu Xu added a comment - I think the default filesystem stripe_size/count/offset in lov_desc is still useful. When user assigned a default stripe_size/count/offset value for a layout component, it can still use the corresponding filesystem default value, otherwise user would has to explicitly specify stripe_size/count/offset values for all layout components.

            People

              laisiyao Lai Siyao
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: