Add MS_MANDLOCK mount failure message #6199
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
|
@behlendorf, thanks for your PR! By analyzing the history of the files in this pull request, we identified @prometheanfire, @slashdd and @dswartz to be potential reviewers. |
Commit torvalds/linux@9e8925b6 allowed for kernels to be built without support for mandatory locking (MS_MANDLOCK). This will result in 'zfs mount' failing when the nbmand=on property is set and the kernel is build without CONFIG_MANDATORY_FILE_LOCKING. Unfortunately we can't detect prior to the mount(2) system call if the kernel was built with this support. The best we can do is check if the mount failed with EPERM and if we passed 'mand' as a mount option and print a more useful error message. e.g. filesystem 'tank' has the 'nbmand=on' property set, this mount option may be disabled in your kernel. Use 'zfs set nbmand=off' to disable this option and try to mount the filesystem again. Additionally, switch the default error message case to use strerror() to produce a more human readable message. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#4729
dinatale2
approved these changes
Jun 7, 2017
gmelikov
approved these changes
Jun 7, 2017
|
@tonyhutter you might also want to consider this small error message fix for 0.6.5.10. |
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this pull request
Jun 7, 2017
Commit torvalds/linux@9e8925b6 allowed for kernels to be built without support for mandatory locking (MS_MANDLOCK). This will result in 'zfs mount' failing when the nbmand=on property is set if the kernel is built without CONFIG_MANDATORY_FILE_LOCKING. Unfortunately we can not reliably detect prior to the mount(2) system call if the kernel was built with this support. The best we can do is check if the mount failed with EPERM and if we passed 'mand' as a mount option and then print a more useful error message. e.g. filesystem 'tank/fs' has the 'nbmand=on' property set, this mount option may be disabled in your kernel. Use 'zfs set nbmand=off' to disable this option and try to mount the filesystem again. Additionally, switch the default error message case to use strerror() to produce a more human readable message. Reviewed-by: George Melikov <mail@gmelikov.ru> Reviewed-by: Giuseppe Di Natale <dinatale2@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#4729 Closes openzfs#6199
|
@behlendorf just added it in |
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this pull request
Jun 8, 2017
Commit torvalds/linux@9e8925b6 allowed for kernels to be built without support for mandatory locking (MS_MANDLOCK). This will result in 'zfs mount' failing when the nbmand=on property is set if the kernel is built without CONFIG_MANDATORY_FILE_LOCKING. Unfortunately we can not reliably detect prior to the mount(2) system call if the kernel was built with this support. The best we can do is check if the mount failed with EPERM and if we passed 'mand' as a mount option and then print a more useful error message. e.g. filesystem 'tank/fs' has the 'nbmand=on' property set, this mount option may be disabled in your kernel. Use 'zfs set nbmand=off' to disable this option and try to mount the filesystem again. Additionally, switch the default error message case to use strerror() to produce a more human readable message. Reviewed-by: George Melikov <mail@gmelikov.ru> Reviewed-by: Giuseppe Di Natale <dinatale2@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#4729 Closes openzfs#6199
tonyhutter
pushed a commit
that referenced
this pull request
Jun 9, 2017
Commit torvalds/linux@9e8925b6 allowed for kernels to be built without support for mandatory locking (MS_MANDLOCK). This will result in 'zfs mount' failing when the nbmand=on property is set if the kernel is built without CONFIG_MANDATORY_FILE_LOCKING. Unfortunately we can not reliably detect prior to the mount(2) system call if the kernel was built with this support. The best we can do is check if the mount failed with EPERM and if we passed 'mand' as a mount option and then print a more useful error message. e.g. filesystem 'tank/fs' has the 'nbmand=on' property set, this mount option may be disabled in your kernel. Use 'zfs set nbmand=off' to disable this option and try to mount the filesystem again. Additionally, switch the default error message case to use strerror() to produce a more human readable message. Reviewed-by: George Melikov <mail@gmelikov.ru> Reviewed-by: Giuseppe Di Natale <dinatale2@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #4729 Closes #6199
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.
Description
Commit torvalds/linux@9e8925b6 allowed for kernels to be built
without support for mandatory locking (MS_MANDLOCK). This will
result in 'zfs mount' failing when the nbmand=on property is set
and the kernel is build without CONFIG_MANDATORY_FILE_LOCKING.
Unfortunately we can't detect prior to the mount(2) system call
if the kernel was built with this support. The best we can do
is check if the mount failed with EPERM and if we passed 'mand'
as a mount option and print a more useful error message. e.g.
filesystem 'tank' has the 'nbmand=on' property set, this mount
option may be disabled in your kernel. Use 'zfs set nbmand=off'
to disable this option and try to mount the filesystem again.
Additionally, switch the default error message case to use
strerror() to produce a more human readable message.
Motivation and Context
Issue #4729
How Has This Been Tested?
Locally.
Types of changes
Checklist:
Signed-off-by.