Details
-
Improvement
-
Resolution: Fixed
-
Major
-
Lustre 2.15.0
-
None
-
3
-
9223372036854775807
Description
I am reaching out to seek clarification regarding the expected behavior of the "lfs setstripe" command when using the -C -1 option.
Currently, it appears that this command is creating a higher stripe count than anticipated. For instance, on my test system, it generated a stripe count of 2727 for a single file. This count exceeds the allowed limit of LOV_MAX_STRIPE_COUNT.
I am uncertain about the appropriate solution to address this issue related to the "-1" argument. I have contemplated the following options:
1. Consider making the option -1 illegal, preventing its usage altogether.
2. Implement a mechanism to automatically set the stripe count to the maximum allowed value (LOV_MAX_STRIPE_COUNT) if the count exceeds this limit.
I would greatly appreciate your input and guidance in this matter. It is worth noting that setting the stripe count higher than LOV_MAX_STRIPE_COUNT leads to other problems, such as the failure of the "llapi_layout_get_by_fd" API to open the file.
Please let me know your input.
Attachments
Issue Links
- is related to
-
LU-17925 sanity-flr test_0b: lfs mirror create: cannot create composite file: Numerical result out of range
-
- Resolved
-
-
LU-17199 'lfs setstripe -C -1' can be set beyond overstripe count > 2000
-
- Resolved
-
-
LU-18244 add 'lfs mkdir -C -N' overstriping support
-
- Resolved
-
- is related to
-
LU-16623 lod_statfs_and_check() does not skip unusable OSTs
-
- Resolved
-
-
LU-13748 'lfs setstripe -C -1' stripes too widely
-
- Resolved
-
But just to be clear, the inconsistency I'm concerned about can ultimately affect files, e.g. by ending up with a MUCH larger overstripe count than perhaps was intended if one accidentally does something like this:
(note the 2727 value is because I don't have Rajeev's other fix on this system, but on the latest code this would be 2000... still probably not what was expected on a system with 2 OSTs).