[LU-13589] PFL "lfs setstripe -E 1M -S 65536" incorrectly parses stripe_size units Created: 20/May/20  Updated: 27/May/20  Resolved: 27/May/20

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.12.4, Lustre 2.12.5
Fix Version/s: Lustre 2.12.5

Type: Bug Priority: Minor
Reporter: Andreas Dilger Assignee: Andreas Dilger
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Related
is related to LU-13168 Client panic "Freechain corrupt"/"Red... Resolved
is related to LU-10070 PFL self-extending file layout Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

Creating a PFL file with "lfs setstripe -E 1M -S 65536 ..." incorrectly transfers the component-end 'M' unit to the stripe_size argument, which results in "65536" being parsed as 65GiB. If the component end is specified as "-E 1G" then the "-S 65536" argument is parsed as 64TiB.



 Comments   
Comment by Andreas Dilger [ 20/May/20 ]

This was seen in the test case for LU-13168 when it was backported to b2_12. It was not seen when the patch was landed on master.

Comment by Andreas Dilger [ 20/May/20 ]

It looks like parsing of "size_units" was reset to 1 for every setstripe argument as part of patch https://review.whamcloud.com/34909 "LU-10070 utils: SEL: lfs find & getstripe support", but it wasn't explicitly called out in the commit message.

Comment by Gerrit Updater [ 20/May/20 ]

Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38680
Subject: LU-13589 utils: fix lfs setstripe unit parsing
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: f6cfe15d9f287ebb6581f84ac135477c30fd5354

Comment by Gerrit Updater [ 27/May/20 ]

Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/38680/
Subject: LU-13589 utils: fix lfs setstripe unit parsing
Project: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: 4e7fd8821da4da2148c5044f416e390c42faf3b8

Comment by Peter Jones [ 27/May/20 ]

Landed for 2.12.5

Generated at Sat Feb 10 03:02:32 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.