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:
parent
c8ae1290d7
commit
12b7198082
1 changed files with 2 additions and 2 deletions
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue