[LU-4298] 'lfs setstripe' with bad values creates an empty file that has no striping information

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.4.0
• Fix Version/s: Lustre 2.7.0, Lustre 2.5.4
• Type: Bug
• Priority: Minor
• Reporter: Sebastien Buisson (Inactive)
• Assignee: James Nunez (Inactive)
• Resolution: Fixed
• Labels: patch
• Severity: 3

Description

Hi,

When launching an 'lfs setstripe' with bad values (for instance a impossible stripe size), it creates an empty file that has no striping information.

It should be better to not create the file at all in that case.

I will propose a patch to address this issue.

Sebastien.

Comments

[Sebastien Buisson (Inactive)]

The patch is at:

http://review.whamcloud.com/8375

Thanks,
Sebastien.

[Peter Jones]

Thanks for the patch Sebastien. James, could you please take care of this issue?

[James Nunez (Inactive)]

This patch works, but there is still a case where we can get files created with no stripe information. When you use the offset option with an a value that is larger than the number of OSTs, you will get an error, but the file will be created with no striping information. llapi_stripe_limit_check checks that offset is less than MAX_OBD_DEVICES, but we never check that the value is less than or equal to the actual number of OSTs before we call open. Thus, we create a file and then get an error when the offset is larger than the number of OSTs.

One option is to mimic what is done for the stripe count (-c) option in lfs setstripe. For the count option, if you use a value that is larger than the number of OSTs, the value is automatically set to the be number of OSTs. The modification of the stripe_count value is done in as part of ll_file_ioctl, in the lov_pack_md routine. The ioctl call is after the calls to llapi_stripe_limit_check and open. Thus, the bad count option is corrected and the file is created with stripe information.

We could do the same for the offset value, i.e. set the value to be the last OST if the input offset value is larger than the number of OSTs. Does this seem like a reasonable way to go?

Otherwise, we need to check the offset value to the actual number of OSTs before we call open.

[Sebastien Buisson (Inactive)]

Hi James,

The logic behind wrong stripe count handling is to use the highest possible number that do not exceed the number of OSTs. But I am not sure we can apply the same logic for stripe offset. I would tend to think it is safer to return an error if the offset is incorrect.

Sebastien.

[James Nunez (Inactive)]

I've updated the patch at http://review.whamcloud.com/#/c/8375 to handle bad input offset/start OST index values.

There is one case that can still create a file with no stripe information; when using pools. If you use lfs setstripe with the "--pool" or "-p" option and you provide a start OST index value for an OST that is not in the pool, a file will be created with no stripe information. I think the fix here is to modify the call to llapi_search_ost to take the OST name of the OST with the input index value.

[James Nunez (Inactive)]

Patch updated to handle all cases where the OST index is specified on the command line is out of range or not in the specified pool.

[Bob Glossman (Inactive)]

backport to b2_5:
http://review.whamcloud.com/12335

[James Nunez (Inactive)]

Patch landed to master