幹壞事是進步最大的原動力
看到「Amazon EFS now supports a larger number of concurrent file locks」這篇提到：
This Amazon EFS update increases the number of simultaneous file locks an NFS mount can acquire to 65,536 (from 8,192 previously), enabling Amazon EFS to be used for a broader set of applications that heavily leverage file locking (including message broker and distributed analytics applications).
所以 NFS 的部份先前有 8192 個的上限在，現在則是拉 65536 個了。
不過提到 message broker，應該是以前的應用利用 NFS file lock 來做一些事情？
上一篇「Amazon EFS 的效能提昇」提到 Amazon EFS 的效能提昇，在 Hacker News 上看到 Amazon EFS 團隊的 PMT (Product-Manager-Technical) 出來回一些東西：「Amazon Elastic File System Update – Sub-Millisecond Read Latency (amazon.com)」，搜尋 geertj 應該就可以看到他回的東西了...
像是即使是 Jeff Barr 發表這篇文章，也還是經過 legal team 的同意才能發表：
(PMT on the EFS team).
Yes, the wordings are carefully formulated as they have to be signed off by the AWS legal team for obvious reasons. With that said, this update was driven by profiling real applications and addressing the most common operations, so the benefits are real. For example, a simple WordPress "hello world" is now about 2x as fast as before.
另外這次的效能提昇是透過 cache 層達成的：
I'm the PMT for this project in the EFS team. The "flip the switch" part was indeed one of the harder parts to get right. Happy to share some limited details. The performance improvement builds on a distributed consistent cache. You can enable such a cache in multiple steps. First you deploy the software across the entire stack that supports the caching protocol but it's disabled by configuration. Then you turn it for the multiple components that are involved in the right order. Another thing that was hard to get right was to ensure that there are no performance regressions due to the consistency protocol.
然後在每個 AZ 都有 cache：
The caches are local to each AZ so you get the low latency in each AZ, the other details are different. Unfortunately I can't share additional details at this moment, but we are looking to do a technical update on EFS at some point soon, maybe at a similar venue!
另外看起來主要就是 metadata cache 的幫助：
NFS workloads are typically metadata heavy and highly correlated in time, so you can achieve very high hit rates. I can't share any specific numbers unfortunately.
還是有很多細節數字不能透漏，但知道是透過 cache 達成的就已經可以大致上想像後面是怎麼弄出來的了...
Jeff Barr 在官方 blog 上宣佈 Amazon EFS 提供 replication 功能：「New – Replication for Amazon Elastic File System (EFS)」。
可以看到跨區的設定畫面：
在建起來以後會是 read-only filesystem：
另外有提供 fail-over 機制，當 fail-over 過去後會從 read-only 變成 read-write。
不過要注意，架構上屬於 eventually consistent，預期是一分鐘內會更新。這點算是可以預期的，不然 latency 會太高：
All replication traffic stays on the AWS global backbone, and most changes are replicated within a minute, with an overall Recovery Point Objective (RPO) of 15 minutes for most file systems.
然後 replication 不會計算到 I/O 的 credit 與 throughput，算是比較特別的一點：
Replication does not consume any burst credits and it does not count against the provisioned throughput of the file system.
replication 這個服務本身不另外收費，只收取 EFS 使用的空間以及 replication 產生的頻寬費用：
You pay the usual storage fees for the original and replica file systems and any applicable cross-region or intra-region data transfer charges.
Amazon EFS 提供 One Zone 的版本，用較低的可靠度提供更低的價錢：「New – Lower Cost Storage Classes for Amazon Elastic File System」。
價錢大約是 53 折，不過要注意不在同一個 AZ 時使用會有頻寬費用：
Standard data transfer fees apply for inter-AZ or inter-region access to file systems.
目前想的到的是 /net/tmp 這類的用途，資料掉了也就算了，考慮到可靠度，其他的用途好像暫時想不到...
先前 AWS Transfer Family 的後端只能是 Amazon S3，現在則是宣佈可以掛 Amazon EFS 了：「New – AWS Transfer Family support for Amazon Elastic File System」。
EFS 跟 S3 都是沒有空間限制，但 EFS 可以直接在系統上掛起來當作一般的檔案系統用，基本上就是更方便，不過代價就是單位儲存成本貴不少...
這次支援 EFS 對於一些量不大的處理又方便不少，也就是處理完後的檔案另外丟，而上傳上來的檔案可以砍掉的... 如果是上傳上來的檔案需要保留的，用 S3 會比較適合。
AWS 宣佈提昇 Amazon EFS 的最低效率：「Amazon Elastic File System increases file system minimum throughput」。
第一段裡的幾個數字差不多就是重點了：
Amazon Elastic File System (Amazon EFS) file systems using the default bursting throughput mode now have a minimum throughput of 1 MiB/s. All EFS bursting mode file systems (regardless of size) can drive 100 MiB/s of throughput, and file systems with more than 1TiB of Standard class storage can drive 100 MiB/s per TB when burst credits are available. This change increases the minimum throughput from 50KiB/s per GiB of Standard class storage to a fixed minimum of 1 MiB/s for file systems with less than 20 GiB of Standard class storage, when burst credits are exhausted.
本來最低保證效率是每 GB 提供 50KB/sec，也就是要使用到 20GB 才會提供 1MB/sec，現在對於不到 20GB 的使用者，直接拉高到固定 1MB/sec。
這對於剛開始用的使用者會方便一些，不過 EFS 主要還是方便在不同機器上共享，效率上還是本機掛 EBS 好很多 (因為 OS 可以 cache)。
先前在 AWS 上把 /home 丟到 EFS 上面，結果因為 i/o 都需要透過網路的關係，編 pyenv 超慢，後來找一天把東西都丟回 EBS 上，速度快多了...
AWS Lambda 可以掛 Amazon EFS 了：「New – A Shared File System for Your Lambda Functions」。
這有點像是一開始 Amazon EC2 只能把資料存到 Amazon S3 上，後來支援 EBS 的感覺：這使得很多程式可以直接用內建的 library 操作檔案系統，而不需要掛 AWS 專用的 library 操作 Amazon S3。
有了一個 filesystem 後馬上就可以想到很多惡搞的方法，像是用 lambda 搞 serverless PHP 之類的，之後應該會看到很有「創意」的玩法...
Colin Percival 提到了 FreeBSD 12.2 上 autofs 會整合 Amazon EFS，讓掛載進來變得更方便：「Some new FreeBSD/EC2 features: EFS automount and ebsnvme-id」。
用法是先設定 autofs，然後啟用 autofs：
# echo '/efs -efs' > /etc/auto_master # sysrc autofs_enable="YES"
然後重開機後就可以直接切到 /efs/FSID 把 EFS 掛起來了：
Having done this, any access to the path
/efs/FSID(e.g.,/efs/fs-01234567) will automatically and transparently mount that filesystem.
另外加上原來對 EBS 與 ephemeral disk 的支援，這樣 storage 的部份算是該有的都有了：
Using the tool and some devd magic, FreeBSD now maintains a tree under /dev/aws/disk containing the symlinks of the forms
- /dev/aws/disk/ebs/vol-0123456789abcdef
- /dev/aws/disk/linuxname/sdh
- /dev/aws/disk/ephemeral/SERIALNO
Amazon EFS 有 IA 的儲存方案，儲存的價位便宜很多，但需要另外收存取費用。不過這對於丟 log 之類的倒是還算方便，很多現有的程式就可以直接往裡面丟...
不過系統的設計上不是讓你指定哪些檔案放到 IA，而是設定 Lifecycle Management Policy 以及時間，當超過指定的時間後就會安排搬到 IA 裡面。
先前最低的時間是 14 天，剛剛看到 AWS 宣佈有 7 天的選項了，從 web console 上就可以看到選項可以選了：「Amazon Elastic File System Infrequent Access Now Supports a 7-day Lifecycle Management Policy」。
這樣對於開始堆資料的人，一開始塞東西進去而需要付 Standard Storage 的時間可以少蠻多的...
Amazon EFS 一直找不太到好用的使用情境，因為 NFS 的關係所以大量 I/O 時的 latency issue 使得速度快不起來，而拿來堆 log 的成本又超級高...
最新推出的 storage class 則是透過提供低儲存成本的版本，解決了堆 log 這種使用情境：「New – Infrequent Access Storage Class for Amazon Elastic File System (EFS)」。
不過 EFS 不像 S3 可以直接選擇 storage class，是需要讓系統管理的：
開啟後 30 天沒有被碰過的檔案就會切過去：
Eligible Files – Files that are 128 KiB or larger and that have not been accessed or modified for at least 30 days can be transitioned to the new storage class. Modifications to a file’s metadata that do not change the file will not delay a transition.
而 latency 也會增加：
Files that have not been read or written for 30 days will be transitioned to the Infrequent Access storage class with no further action on your part. Files in the Standard Access class can be accessed with latency measured in single-digit milliseconds; files in the Infrequent Access class have latency in the double-digits.
以 us-east-1 為例子來說，Standard 是 USD$0.3/GB-month，而 IA 只要 USD$0.045/GB-month，但抓取時會有 USD$0.01/GB 的傳輸費用，可以看出價錢低不少。
不過文章裡沒提到什麼時候會把資料從 IA 跳回 Standard，可能得找機會問問看...