5.2.1 Workload Characteristics
This experiment adopted the SQLite benchmark and the file-access benchmark in An-droBench. The SQLite benchmark has three tests, i.e., insert, update, and delete. Each of the test performed 300 transactions. The TPS index is separately computed for each test
SQLite File access File data read (MB) 25.5 (59.6%) 191.8 (81.4%) File data written (MB) 17.3 (40.4%) 43.8 (18.6%)
Avg. fread() record size (KB) 3.1 7.9
Avg. fwrite() record size (KB) 1.6 28.4
fwrite() call counts 11,329 1,579
fsync() call counts 4,533 1,519
Table 5.2: File access characteristics of the SQLite and file-access benchmarks
(a) (b) (c)
Figure 5.1: Evaluation results of the original ext4 synching and the proposed eager synching in the SQLite benchmark. (a) Eager synching improved the Transaction per Second by up to 50%. (b) The original ext4 synching randomly distributed write requests among the ext4 journal and the database files. (c) Eager synching re-directed the write requests of the synched file to the ext4 journal, making the disk write pattern more sequential.
by dividing 300 by the time spent on each test. The file-access benchmark is composed of four tests on file accessing: random read, sequential read, random write, and sequential write. The two read tests and the two write tests accessed total amounts of 191 MB and 43 MB of data, respectively. The file record sizes of the sequential tests and the random tests were 256 KB and 4 KB, respectively. The throughput of the four tests are separately computed by dividing the transfer size of a test by the time spent on the test.
We captured the file operations produced by the two benchmarks, and the characteristics of their file access behaviors are shown in Table 5.2. The SQLite benchmark wrote as much as it read, while the file-accessing benchmark read more. The average write size of the SQLite benchmark is small, while that of the file-accessing benchmark is larger. Even
0.5
█Ext4 Synching ╳Asynchronous Write
┼Synchronous Write ╳Asynchronous Write
┼Synchronous Write
(a) (b) (c)
Figure 5.2: Evaluation results of the original ext4 synching and the proposed eager synching in the file-accessing benchmark. (a) Eager synching performed much better than ext4 synching in the random write test. (b) The original ext4 synching produced many write requests to both the journal and the test files. (c) Eager synching wrote data to the journal when synching files and reduced the write count to the test files.
though the write size of the latter is larger, it used small record size (4 KB) in the random write test. Both the SQLite benchmark and file-accessing benchmark performed fsync() at very high frequencies: the former issued an fsync() for almost every two fwrite() operations, while the latter called fsync() after almost every fwrite() operation.
5.2.2 Evaluation Results of SQLite Benchmark
Figure 5.1 shows the evaluation results of the SQLite benchmark using the original ext4 synching and our eager synching. Figure 5.1(a) indicates that eager synching noticeably improved upon ext4 synching in terms of TPS by up to 50%. There are two reasons for the significant improvement: a higher write sequentiality and a larger average write request size. First, when a file is being synched, the ext4 synching method wrote the dirty data directly to the file-system image, causing random in-place updates to the flash storage.
Differently, eager synching redirected the dirty data to the sequential journal, producing sequential out-of-place updates in the journal. The file system generated in-place writes to the database files by the end of every journal committing interval. Figure 5.1(b) depicts the write pattern of the ext4 synching method, and the sequential ratio was 0%. Eager synching reshaped the write pattern to be more sequential, as shown in Figures 5.1(b), and
the sequential ratio was boosted to 65.03%.
Second, to synch a file, the ext4 synching method flushed all the dirty data to the storage, and thus dirty data could only stay in the page cache for a short period of time.
As a result, the ext4 synching method produced many small write requests. On the other hand, eager synching wrote only the data associated with the files being synched, and dirty data accumulated in the page cache for a longer period of time. Later on, when the file system submitted the dirty data to the block driver of the flash storage, the I/O scheduler merged many adjacent requests into larger ones. We found that the average request size of block write of the ext4 synching method was 10.1 sectors, while that size of eager synching significantly increased to 23.0 sectors. Writing the flash storage with large requests reduces the I/O path overhead and increases the write sequentiality.
In this experiment, eager synching slightly increased the total amount of data written to the flash storage (38.7 MB vs. 41.1 MB). We observed that the SQLite benchmark did not frequently overwrite existing data in the database files. In other words, there were not many temporal localities in the file-writing operations. As discussed in Section 4.4, if the page cache does not much reduce the write traffic, then eager synching can write slightly more data than the ext4 synching method. However, because eager synching still boosted the write performance, the cost of writing the extra amount of data was completely compensated by the benefit of making the write pattern sequential.
5.2.3 Evaluation Results of File-Accessing Benchmark
Figure 5.2 shows that 1) eager synching achieved a remarkable performance improvement in the random-write test, 2) eager synching did not suffer from performance degradation in the sequential-write test, and 3) eager synching does not affect the performance of the two read tests. For the random-write test, like the results of the SQLite benchmark, the write patterns in Figures 5.2(b) and 5.2(c) show that eager synching successfully prevented from producing random write to the journal and test files. In addition, compared to the block-level average write request size of using ext4 synching, using eager synching increased the size from 18.6 sectors to 46.4 sectors. As mentioned above, writing with large requests
0
Figure 5.3: Evaluation results of the macro-benchmark. (a) Eager synching noticeably improved the write throughput under the workloads of the three Android applications. (b) Write pattern using ext4 synching is full of many small and random writes. (c) Write pattern using eager synching becomes less requests and more sequential.
is beneficial to the write performance. Another factor contributing to the performance improvement is that using eager synching decreased the total amounts of data written to the flash storage from 39.4 MB to 34.9 MB. As mentioned in Section 5.2.2, this comes from ignoring commit record writing.
Eager synching did not degrade the performance of the sequential-write test because, as illustrated in Section 4.3, the file system performs the original ext4 synching if it finds the amount of data to be synched larger than a threshold. This design prevents the file system from re-directing a sequential stream to the journal. As to the two read tests, eager synching did not affect their performance since the file system never reads the journal on cache misses. This is because a piece of cached file data can be released from the main memory only after the file system allocates disk space for the data and writes the data back to the allocated space.
This may stem from the fact that Eager Log tends to roll-back on detecting large requests.
In some cases, requests size may vary across the roll-back threshold back and forth, thus making part of requests written in journal by Eager Log are forced to be written again by journaling mechanism. This reduces hot data to accomodate more writes, and thus the amount written is enlarged. Even so, Eager Log still benefits from sequential writes as
Facebook Gmail Chrome File data read (MB) 39 (43.7%) 198 (44.1%) 13 (5.3%) File data written (MB) 50 (56.3%) 251 (55.9%) 238 (94.7%)
Avg. fread() size (KB) 1.55 3.49 0.42
Avg. fwrite() size (KB) 3.36 2.12 2.69
fwrite() calls 15,369 120,971 90,638
fsync() calls 2,875 6,385 575
Different files accessed 370 135 721
Table 5.3: File access characteristics of the three applications in our macro-benchmark.
flash memory is good at it.