[LU-7335] store default filesystem layout directly on root inode Created: 24/Oct/15 Updated: 10/Sep/16 Resolved: 10/Sep/16 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.9.0 |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Andreas Dilger | Assignee: | Lai Siyao |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | medium | ||
| Issue Links: |
|
||||||||||||||||
| Rank (Obsolete): | 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. |
| Comments |
| Comment by Zhenyu Xu [ 22/Feb/16 ] |
|
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. |
| Comment by Zhenyu Xu [ 22/Feb/16 ] |
|
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. |
| Comment by Andreas Dilger [ 22/Feb/16 ] |
|
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. |
| Comment by Niu Yawei (Inactive) [ 23/Feb/16 ] |
|
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? |
| Comment by Andreas Dilger [ 25/Feb/16 ] |
|
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. |
| Comment by Andreas Dilger [ 02/Sep/16 ] |
|
Lai, can you please verify that this issue is fixed with your patch http://review.whamcloud.com/19041 " If closing, please add "Fix Version: 2.9.0" for all of these tickets also. |
| Comment by Andreas Dilger [ 10/Sep/16 ] |
|
This was fixed as part of patch http://review.whamcloud.com/20348 " |