1
0
Fork 0
mirror of https://github.com/nickpoida/og-aws.git synced 2025-02-13 10:21:57 +00:00

Fix incorrect EFS information

This commit is contained in:
Benjamin Wilson 2016-12-13 20:53:53 -05:00 committed by GitHub
parent c8ae1290d7
commit 12b7198082

View file

@ -943,8 +943,8 @@ EFS
- 🔸 A number of NFSv4.1 features are [not supported](http://docs.aws.amazon.com/efs/latest/ug/nfs4-unsupported-features.html) and there are some [limits](http://docs.aws.amazon.com/efs/latest/ug/limits.html) to the service.
- 🔸 As of 2016-11, EFS does not offer disk level encryption, though it is on the roadmap.
- ❗ Some applications, like SQLite and IPython, [might not work properly](https://sqlite.org/faq.html#q5) on EFS when accessed from multiple clients. This is because lock upgrades and downgrades are [not supported](http://docs.aws.amazon.com/efs/latest/ug/nfs4-unsupported-features.html). There might be [workarounds](https://github.com/ipython/ipython/issues/882) for some issues.
- 🔸 Mounting EFS over VPN connection, VPC peering, or AWS Direct Connect is not supported.
- 🔸 Using an EFS volume on Windows is not supported, apparently due to Microsoft implementing NFS differently.
- 🔸 Mounting EFS over VPN connection, VPC peering, ~~or AWS Direct Connect~~ is not supported. EFS [does support](https://aws.amazon.com/efs/faq/#on-premises) mounting over Direct Connect.
- 🔸 Using an EFS volume on Windows is not supported because while the server service supports NFS v3 and v4.1, the client only supports NFS v3.
- ⏱ When a file is uploaded to EFS, it can take hours for EFS to update the details for billing and burst credit purposes.
- 🔸⏱ Metadata operations can be costly in terms of burst credit consumption. Recursively traversing a tree containing thousands of files can easily ramp up to tens or even hundreds of megabytes of burst credits being consumed, even if no file is being touched. Commands like ```find``` or ```chown -R``` can have an adverse impact on performace if run periodically.
- 🔸 Mount points are AZ-based. In an Auto scaling group spread across zones, you can end up with instances in one zone mounting EFS from a different zone. That might decrease performance and would create an unintended single point of failure. One way to fix it would be [a shell script](https://gist.github.com/bgdnlp/9fd326dc4a23f46bab93a1eade023fe4) that runs before network drives are mounted and edits /etc/fstab with the proper AZ.