幹壞事是進步最大的原動力
GitHub 發了一篇公告說明這件事情：「Vulnerability announced: update your Git clients」，而 Git 官方的公告在這邊：「[ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)」。
這次的問題起因很好理解，就是有人可以在 repository 裡面放 .GIT 這樣的目錄名稱，配合將大小寫視為一樣的檔案系統 (Windows 系列用的 FAT 與 NTFS、Mac 用的 HFS+)，裡面就可以放各種設定值，有機會在 checkout 下來時就執行，或是透過其他的 git 指令執行。
GitHub 在 server 端擋下來了，不過還是建議 client 端趕快更新到最新版，這些版本會從 client 端擋下這些路徑。
這次 CVE 編號是 CVE-2014-9390，不過 NIST 的資料庫裡面沒有列出來？
今年一月的時候，Netflix 曾經寫過一篇關於對 S3 的 Eventually Consistency 的問題：「Netflix 對 S3 的 Eventually Consistency 的補強...」，當時 Netflix 的作法是實做 s3mper 以確保一致性。
過了半年，AWS 的人在 EMR 上實做了類似的功能：「Consistent View for Elastic MapReduce's File System」。
看文章的說明，應該是用到 DynamoDB 負責 S3 上資料的狀態，而 DynamoDB 的資料並不會砍掉，所以在使用時要注意這點 :o
Percona 的「How to improve InnoDB performance by 55% for write-bound loads」這篇在討論 Journal filesystem 以及 InnoDB 的 Double write buffer。
先講文章內的結論。
在 ext4 上開啟 Journal filesystem 功能後並且關掉 InnoDB 的 Double write buffer 後，資料的安全性不受影響，但效能上升非常多。而與目前常用的 XFS 比較起來也是領先不少。
要注意的是，這邊的數據是資料大小小於記憶體大小時 tpcc-mysql 的執行數據。
原文還有探討其他的狀況，像是 InnoDB 與 MyISAM 混用的問題，有用到的人應該自己去看看原文。
而目前在公司用 XFS 已經用習慣而且相當穩定，但該來花時間投資在 ext4 了，常常可以看到 ext4 很不錯之類的消息。
有人對 VMware 以及 VirtualBox 測試效能：「Comparing Filesystem Performance in Virtual Machines」，有四張圖：
不過數字怪怪的，NFS 那邊是怎樣 XDDD
看看就好，如果有用到再自己測試看看吧？
在 Slashdot 上看到「Denial-of-Service Attack Found In Btrfs File-System」覺得很有趣，結果一看，又是 hash collision... XD
一年前的「n.runs-SA-2011.004 - web programming languages and platforms - DoS through hash table (PDF)」打爆所有主流語言，沒想到在 filesystem 上也發生了 XDDD
不知道要怎麼修正... (已經存在的資料要怎麼 migrate？incompatible change？)