Change:
readOnly:     readOnly, mounter:      &mount.SafeFormatAndMount{Interface: mounter, Exec: exec}, deviceUtil:   util.NewDeviceHandler(util.NewIOHandler()), <del> mountOptions: []string{}, </del> <ins> mountOptions: util.MountOptionFromSpec(spec), </ins> }, nil } return &fcDiskMounter{

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently many in-tree storage plugins, including the iSCSI plugin, support mount options. The FC plugin does not. I have poked around the code enough to know where the plugin reports that mount options are not supported, but it isn't clear to me WHY they aren't supported. Why is this needed: Mount options can drastically change the performance and data persistence characteristics of a filesystem. For example, "noatime" can reduce metadata operations on frequently read data or "sync" can ensure all writes go immediately down to a backing storage array. I am working on a deployment across an FC backed cluster for which the the containerized application benefits from specific mount options, and I would guess other users might find similar use cases. It seems to me that if mount options are supportable on iSCSI, they should be equally supportable on FC, but I certainly recognize the possibility that I may be missing something. Otherwise, I'm guessing they simply haven't been a priority?
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/good-first-issue /help
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Yeah, we just miss a volunteer that would implement this feature. It should be relatively easy and straightforward, following iscsi as an example.
I would like to work on it! As this my first issue I would like to get some help.
/assign sathish-thangaraj
GitHub didn't allow me to assign the following users: sathish-thangaraj. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time.

For more information please see <detailsIn response to : /assign sathish-thangaraj Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
that's great! I was going to write detailed info how to fix this, however, I found out that mount options should work, at least in Kubernetes 1.13, see this commit: So there is a simple bug somewhere. Looking around the code, this code smells fishy: . Can you check with "BlockVolume" feature turned off in kubelet, i.e. ? Mount options should work there. And then it should be fairly easy to fix it in .
It definitely looks like there's an issue there. I don't think the kubelet ever made it that far in my initial testings, as mounting (with mountOptions listed in the PersistentVolume object) failed with the following message: I assume this is related to the following code: Is there a way to disable a check like this without rebuilding all of Kubernetes?
Good catch! No. IMO it should be enough to rebuild kubelet here and it's fast and easy: and find it somewhere in .
Thanks for the help so far I flipped the SupportsMountOption() bool to "true" and the BlockVolume feature gate to false. I was then able to mount an ext4 volume with the "noatime" and "nodiratime" option (confirmed on the worker node). However, I attempted to use the "nobarrier" option but the worker node mounted the volume without it. Finally, I attempted to use a completely made-up option ("hello"). The volume did not fail to mount (as is suggested in the Kubernetes documentation. Instead, it mounted without the "hello" options. I am attempting to locate useful logs to try to understand why some mount options are ignored or why incorrect mount options aren't causing failures, but the kubelet logs haven't been helpful thus far. Unfortunately I don't currently have any easy access to any iSCSI equipment for comparison.
anyone working on this?
is there anywhere that I could help on the issue?
First time contributor here - I just changed 2 lines of code to make FC similar to other volume types (eg. iSCSI).

I'm not sure about the mount option validation that mentions. Should that be a separate issue?
Apologies for the extreme delay in keeping up with this issue. I believe the issue with ignored mount options may be more generally related to the way the Linux mounter (/pkg/utils/mount/mount-) handles mount options, although I don't have enough experience with other volume plugins to speak authoritatively on the issue. I recommend we try to get the basic changes suggested above into the code, as my limited testing shows them to be effective for at least some mount options. I'd try to submit a pull request myself, but I don't want to take it from as they've already put forth the work to get it started.
To clarify my previous comment, during Attach, the FC volume plugin mounts an FC volume to a global path with no mount options. During Mount, the Linux mounter bind mounts (-o bind) and bind remounts (-o bind,remount) an FC volume to a Pod specific path with mount options. However, the bind remount action is only capable of applying a limited number of mount options (those not on the list are silently ignored). In order to expand our mount option capabilities, we would (I believe) need to use mount options in the Attach phase.
First time contributor, taking this one /assign
you are, of course, welcome to work on this issue. However, I wanted to let you know that I made code changes back in November that (I believe) address my previous comments. I only received approval from my employer in the last couple of days to make the contributions, or I would have submitted them already. I plan to clean things up and get a PR in sometime this afternoon. I am also a first time contributor, so we'll see how it goes. /assign
No problem at all dude. You take this one since you already made the changes. On Thu, 23 Jan 2020 at 18:47 Eric Weber <: