Amazon EFS - Risk of access interruption due to misconfigured EFS mounts

Hey there.

We’ve received the notification below from AWS, and apparently when mounting EFS volumes (by means of having defined volumes in convox.yml) noresvport mount option should be specified.

First of all, do you think this would actually cause any service disruption for convox racks?

And, ultimately, I hope this can be fixed in a rack update.

Thanks!
Ali for the Balsamiq team

[Action Required] Amazon EFS - Risk of access interruption due to misconfigured EFS mounts [AWS Account: *REDACTED*] [EU-WEST-1]

Hello,

You are receiving this message because one or more of your Amazon EFS file systems are mounted using settings that could cause your clients to lose access to your file system data. Specifically, these file systems have been mounted without the 'noresvport' option, which may require you to restart the instances running your NFS clients to re-establish connection with the server in case of a disconnection event.

For context, EFS provides shared file storage that is accessible via industry-standard NFS protocol. NFS clients are designed to automatically re-connect in case of interruption to minimize the impact of routine disconnections on application performance and availability. However, Linux kernel versions that do not apply a patch described in [1], include a behavior that causes NFS clients to — upon disconnection — continue to attempt reconnections on the same TCP source port. This behavior does not comply with the TCP RFC, and can prevent these clients from quickly reestablishing connections to their NFS server (in this case, an EFS file system). To avoid this issue, we recommend mounting the file system using the 'noresvport' option which causes NFS clients to reestablish connections using new TCP source ports. The 'noresvport' option is automatically applied when you mount file systems using EFS mount helper [2].

We have identified that the following EFS file systems have been mounted without the recommended 'noresvport' option:
fs-*REDACTED*


Starting October 1, 2023, EFS will begin a network upgrade to deliver lower-latency access to your EFS file system data. As with most routine EFS updates, this upgrade will cause existing NFS clients to reestablish connectivity with your EFS file system(s). If you do not update these clients to use EFS’s recommended mount settings, this upgrade may require you to restart compute instances running the affected NFS clients in order to recover their access to your EFS file system data.

# Action Required:
To minimize the risk of disruption, we recommend you re-mount your EFS file system(s) using the EFS mount helper [2] (or manually apply the 'noresvport' option if you are unable to use the EFS mount helper) by October 1, 2023.

The EFS mount helper [2] automatically applies mount settings that are optimized for Amazon EFS file systems, including 'noresvport', to help ensure clients can seamlessly reestablish connectivity in the event of disruption. If you cannot use the EFS mount helper, we strongly recommend manually applying the 'noresvport' option when mounting your EFS file system. For more information, please see 'Recommended NFS mount option' [3] in the EFS documentation.

If you are unable to update your file system mount settings or have any questions, please reach out to AWS Support [4].

[1] https://github.com/torvalds/linux/commit/e6237b6feb37582fbd6bd7a8336d1256a6b4b4f9
[2] https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html
[3] https://docs.aws.amazon.com/efs/latest/ug/mounting-fs-nfs-mount-settings.html
[4] https://console.aws.amazon.com/support/home
1 Like

We got the same message - for two of our EFS volumes, both quite old (created 5 years ago).

Will the latest version of Convox correct this issue before the October 1st date?

We also got the same email from AWS.
Which version of Convox is supposed to fix the issue?

Good morning everyone,

We have resolved this with rack version 20230912230919.

Please update your racks to avoid any unnecessary interruptions once this mount configuration changes are live on AWS.

Regards,
Nick

Thanks!