https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4298 Lustre <p>Hi,</p> <p>When launching an 'lfs setstripe' with bad values (for instance a impossible stripe size), it creates an empty file that has no striping information.</p> <p>It should be better to not create the file at all in that case.</p> <p>I will propose a patch to address this issue.</p> <p>Sebastien.</p> LU-4298

'lfs setstripe' with bad values creates an empty file that has no striping information

Bug Minor Resolved Fixed James Nunez Sebastien Buisson patch Fri, 22 Nov 2013 14:35:23 +0000 Thu, 6 Nov 2014 21:52:25 +0000 Sat, 18 Oct 2014 23:32:34 +0000 Lustre 2.4.0 Lustre 2.7.0 Lustre 2.5.4 0 5 <p>The patch is at:</p> <p><a href="http://review.whamcloud.com/8375" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/8375</a></p> <p>Thanks,<br/> Sebastien.</p> <p>Thanks for the patch Sebastien. James, could you please take care of this issue?</p> <p>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.</p> <p>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. </p> <p>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? </p> <p>Otherwise, we need to check the offset value to the actual number of OSTs before we call open.</p> <p>Hi James,</p> <p>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.</p> <p>Sebastien.</p> <p>I've updated the patch at <a href="http://review.whamcloud.com/#/c/8375" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/8375</a> to handle bad input offset/start OST index values. </p> <p>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.</p> <p>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.</p> <p>backport to b2_5:<br/> <a href="http://review.whamcloud.com/12335" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/12335</a></p> <p>Patch landed to master</p> Development Rank 1|hzw9y7: Rank (Obsolete) 11782 Severity