最近，在測試基於ceph的小文件合並方案（見上個博文）時，遇到一個怪異的現象：將librados提供的append接口與我們封裝的WriteFullObj接口(osd端是append操作和kvdb的put操作)對比，在處理同樣大小的文件時(如4KB，8KB等)，WriteFullObj比librados的append操作tps低很多，最初懷疑可能是kvdb的put操作的原因，后來將osd端kvdb的put臨時去掉，tps仍然上不去；后來使用iostat觀察osd上狀態，發現WriteFullObj時，uitl在50%左右，wait cpu在40左右，而librados的append則沒這么高。。。。。。。。。。。再仔細觀察，WriteFullObj時，r/s對應read操作在30甚至更高，而librados的append則幾乎為0。。。。。。。。。。再比較二者的差異，將librados的append操作在剛剛WriteFullObj操作的文件，現象和WriteFullObj一樣了。。。。再比較兩個操作的文件差異，WriteFullObj操作文件大小非4KB整數倍，非4KB整數倍大小是在情理之中，因為合並時，每個小文件數據前附加了36B大小的元數據描述信息，但這為什么會影響寫的性能表現和上述現象呢？腦中閃現以前做磁盤分區時遇到的情況：“warning：partition is not properly aligned for best performance”；那么在讀寫文件時，是否也要類似地保持alignment以提升性能呢？
經過研究結果如下：
扇區（sector)是磁盤的最小存儲單位，通常為512B；塊(block)是文件系統中存取的最小單位，通常為1024、2048或4096B，塊也是文件系統分配和回收空間的最小單位；
當write向文件末尾追加數據時，文件系統會嘗試為數據分配數據塊，如果是對數據塊的部分寫入操作，則需要先將數據塊的數據讀出(此時可能會被阻塞)，然后再整體寫入(fetch-before-write)；
當一個磁盤文件大小非4KB(塊大小)整數倍大小，在文件末尾追加數據就是上述的部分寫入操作，從而出現上述read操作很高的現象；
為了證實上述結論，測試如下：
A. 文件系統塊大小4KB，調用librados的append操作，每次append數據量大小為1KB，文件最初不存在；
B. 用iostat查看，第4k+1次append時,read量幾乎為0；第4k+2、4k+3、4k+4次append時，read量開始飆升；
符合預期；
同樣原理，跨block讀也無法將系統性能充分發揮；
為了充分提供系統性能，設計存儲結構時就需要避免此類情況，業界常用的方案就是padding，write操作在4KB整數位置處；
參考：
http://www.seagate.com/cn/zh/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/
https://blogs.oracle.com/dlutz/entry/partition_alignment_guidelines_for_unified
https://www.usenix.org/system/files/conference/fast15/fast15-paper-campello.pdf
http://www.storage-switzerland.com/Articles/Entries/2011/10/27_Improving_VMware_Storage_I_O_Performance_By_Realigning_Partitions.html
http://www.storagereview.com/the_impact_of_misalignment
http://noops.me/?p=747
------------------------------------
http://www.cnblogs.com/wuhuiyuan/p/4760030.html
個人原創，轉載請注明出處。