iSCSILogicalUnit: do not use lio_iblock with lio-t #1704
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For lio-t, we cannot use the lio_iblock parameter, as targetcli just ignores the index we give it and generates its own. A logical consequence is that we cannot use the contents of the lio_iblock parameter to access the iblock_* directories in the configfs, since we do not know the values of the indices generated by targetcli. This leads to an effect where systems with only one target work just fine: targetcli always picks "0" as the first index, and the default value of lio_iblock is "0". But when multiple targets are involved, one of them will get the index "1" whereas we are still trying to access "iblock_0", leading to errors of the form: /sys/kernel/config/target/core/iblock_0/lu1_target1/wwn/product_id: No such file or directory Since we only ever want to access the target directory inside the iblock_* directory, we can just use a glob to sufficiently describe the path -- there should always only be one match.
|
Can one of the admins verify this patch? |
|
ok to test |
|
LGTM. Thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For lio-t, we cannot use the lio_iblock parameter, as targetcli just
ignores the index we give it and generates its own.
A logical consequence is that we cannot use the contents of the
lio_iblock parameter to access the iblock_* directories in the configfs,
since we do not know the values of the indices generated by targetcli.
This leads to an effect where systems with only one target work just
fine: targetcli always picks "0" as the first index, and the default
value of lio_iblock is "0". But when multiple targets are involved, one
of them will get the index "1" whereas we are still trying to access
"iblock_0", leading to errors of the form:
/sys/kernel/config/target/core/iblock_0/lu1_target1/wwn/product_id: No such file or directory
Since we only ever want to access the target directory inside the
iblock_* directory, we can just use a glob to sufficiently describe the
path -- there should always only be one match.