用於使用快閃儲存的Android裝置上F2FS檔案系統之快速檔案同步設計

Abstract

隨著手持裝置的用戶不斷增加，應用程式的設計者不斷在效能和其他議題上絞盡腦汁，期望獲得更多使用者的青睞。在資料一致性議題上，許多的應用程式都使用SQLite來管理它們的資料，但根據研究顯示SQLite會產生過多的檔案同步操作 (fsync()呼叫)；而實際上fsync()呼叫存在許多的缺點，會導致應用程式的效能不佳：首先，fsync()是一個阻塞呼叫，若其在操作過程中缺乏效率，則會影響應用程式的回應時間；其次，fsync()是一個同步呼叫，它會產生許多小筆且隨機的寫入，這對於使用快閃記憶體為儲存體的安卓裝置造成諸多不利，包括頻繁的垃圾收集和減少快閃記憶體壽命。 本篇研究提出更有效率的檔案同步處理方式，我們命名為迫切同步，並將其實作在F2FS檔案系統上。我們藉由增加平均寫入要求的大小，減輕 I/O處理負擔，並降低寫入串流的個數改善寫入循序度；此外降低整體的寫入量，進而延長快閃儲存裝置的壽命。我們在Google Nexus 7上進行一連串的實驗且結果顯示，在多個受歡迎的安卓應用程式的工作量下，平均和最大的fsync()延遲能分別減少68%和82%，且區塊階層的總寫入量最多可減少20%。

Nowadays, more and more users start to use hand-held device. They care about not only the price but also the application performance. Therefore, programmers always try their best to improve application performance and concern other design issues. To maintain the consistency of data, many popular applications manage their data using SQLite. However, Recent research pointed out that the SQLite involves frequent file synching operations (i.e., fsync() calls). Fsync() calls have many shortcomings which may degree the application performance: First, fsync() is a blocking call that applications could suffer from poor response if the fsync() implementation is inefficient. Second, fsync() is a synchronous call that would cause a lot of small-sized and random write operations. These write operations might incur frequent garbage collections as well as shorten the lifetime of flash-storage-based Android device. This work purposes an efficient design of fsync() called eager synching. We have implemented eager synching on F2FS file system. By increasing the size of average block request and decreasing write streams, we can alleviate I/O overhead and improve write sequential ratio respectively. Besides, the lifetime of the underlying NAND flash storage would be extended by reducing block write traffic. We conducted a series of experiments on Google Nexus 7 tablet. Our experimental results show that, under the workloads of popular Android applications, the average and max fsync() latencies were reduced by up to 68% and 82%, respectively, and the block-level write traffic was reduced by up to 20%.