幹壞事是進步最大的原動力
Dropbox 去年的時候拔掉非 ext4 檔案系統的支援，被罵翻也不鳥 (參考「Linux 版的 Dropbox 在十一月後將只支援 ext4...」)，結果現在又回來支援了：「Dropbox Brings Back Support For ZFS, XFS, Btrfs And eCryptFS On Linux」。
出自 beta 版的說明「Beta Build 77.3.127」這邊：
Add support for zfs (on 64-bit systems only), eCryptFS, xfs (on 64-bit systems only), and btrfs filesystems in Linux.
不過我不是因為這個而搬走 (因為我用 ext4)，反而是在對免費版限制時跳走：「Dropbox 免費版限制三個裝置更新...」。
當初用 X-attrs 當理由，看起來是有人離職了所以就加回來...
有人收到 Dropbox 在十一月後不支援的訊息，在官方論壇上問起：「Dropbox client warns me that it'll stop syncing in Nov, why?」。
不過下面的人提到了很多 filesystem 都支援：(引用自維基百科的「Extended file attributes」)
In Linux, the ext2, ext3, ext4, JFS, Squashfs, Yaffs2, ReiserFS, Reiser4, XFS, Btrfs, OrangeFS, Lustre, OCFS2 1.6 and F2FS filesystems support extended attributes (abbreviated xattr) when enabled in the kernel configuration.
然後就吵起來了... 翻了一下，目前看起來還是沒打算支援 :o
好像是個換到 Syncthing 的機會，先前只丟了音樂在上面。來研究一下 Syncthing 上面要怎麼疊 encrypted filesystem 來放其他資料...
Percona 的 CTO Vadim Tkachenko 在比較 InnoDB 與 MyRocks 時意外發現了 binlog 會影響不少效能穩定性，再加上 MySQL 8.0 有改變 binlog 相關的預設值，所以他後續花了不少時間測試，寫了兩篇關於 binlog 對於 MySQL 效能的影響：「How Binary Logs (and Filesystems) Affect MySQL Performance」與「How Binary Logs Affect MySQL 8.0 Performance」。
第一篇是想要知道在 Percona Server 5.7 上開 binlog 的影響，做出來後可以看到明顯的效能波動 (因為 binlog 導致 flush 時效能暴跌)：
而其中的 workaround 就是調整 flush 參數，讓他比較頻繁的小量寫入，而不是突然要寫很多資料。這樣一來對平均效能也許比較差，但對前端應用衝擊會比較小：
在測試可以看到 sync_binlog=1000 是個妥協點。各單位要自己去找出適合的數字：
The strict setting also comes with noted performance penalties. I will also test sync_binlog=1000 and sync_binlog=10000, which means perform synchronous writes of binary logs every 1000 and 10000 transactions, respectively.
另外有測試 ext4 與 XFS 是否有影響，就測試的結果看起來 ext4 比 XFS 好一些，但差距有限：
第二篇則是拿 MySQL 8.0 與 Percona Server 5.7 比較，可以發現在 MySQL 8.0 開啟 binlog 時有時會有不少的效能損失：
It seems that binary logs have quite an effect MySQL 8.0, and we see up to a 30% performance penalty as opposed to the 13% for Percona Server for MySQL 5.7.
雖是推銷一下自家產品在這塊還不錯 XD
在「Application crash consistency and performance with CCFS」這篇看到的東西。
CCFS 目標是拉高 ext4 的 data integrity，並且還是有高效能：
CCFS (the Crash-Consistent File System) is an extension to ext4 that restores ordering and weak atomicity guarantees for applications, while at the same time delivering much improved performance.
如果你需要絕對的 data integrity，你需要用 data=journal 確保資料可以在 system crash 後被 replay，預設的 data=ordered 是無法達到的，而 CCFS 也沒打算達到絕對的 data integrity，而是盡量達到。所以在測試上可以發現 CCFS 大幅改善了 data integrity：
而效能還提昇了 (喂喂)：
這真是太神奇了...
翻了一下好像沒 open source 出來 (至少現在沒看到)，來等看看有沒有人會實做出來...
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 很不錯之類的消息。
Slashdot 上看到 Debian 7.0 預定在五月第一個週末出版：「Debian 7.0 ('Wheezy') Release Planned For 1st Weekend in May」，在「NewInWheezy」可以看到有哪些變動。
ext4 變成 default filesystem，然後透過 FUSE 支援 exFAT。
上次的 Debian 6.0 是 2011 年 2 月 6 日，兩年多了... 還是維持一貫的更新速度... XD