[LU-13611] DoM component inherited from parent/ROOT does not honor lod.*.dom_stripesize limit Created: 29/May/20 Updated: 05/Oct/21 Resolved: 05/Oct/21 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Andreas Dilger | Assignee: | Mikhail Pershin |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
It appears that if lod.*.dom_stripesize is set on the MDT, then it prevents setting new explicit/default layouts on files/directories via "lfs setstripe", but it does not affect the inheritance of DoM components from parent/ROOT default layouts. The following commands show this: $ lfs setstripe -E 1M -L mdt -E eof -c 1 /mnt/testfs $ lctl set_param lod.*.dom_stripesize=64K $ touch /mnt/testfs/dom $ lfs getstripe /mnt/testfs/dom The dom file is created with a 1MB DoM component instead of a 64KB DoM component. I wonder if it makes sense to use the new "lod.*.dom_stripesize_max_kb" parameter to control the maximum amount of space for DoM components as they are created, while the older "lod.*.dom_stripesize" parameter would control what the maximum DoM component size can be specified by "lfs setstripe"? Alternately, we could just consider this existing behavior as a bug and change new files to be limited to "dom_stripesize" regardless of where the parameter came from. |
| Comments |
| Comment by Mikhail Pershin [ 29/May/20 ] |
|
yes, this should be fixed. As for dom_stripesize param, I wouldn't make it another parameter but keep it the same with dom_stripesize_max_kb |
| Comment by Andreas Dilger [ 05/Oct/21 ] |
|
It looks like this is virtually identical to |