• Journal of KIISE
• /
• v.44 no.4
• /
• pp.363-373
• /
• 2017

Ext4 file system is widely used in various computing environments such as those of the PC, the server, and the Linux-based embedded system. Ext4, which uses a buffer for block I/O, provides fsync() system call to applications to guarantee the consistency of a specific file. A log of the analytical studies regarding the operation of Ext4 and the improvement of its performance has been compiled, but it has not been studied in detail in terms of kernel versions. We figure out that the behavior of fsync() system call is different depending on the kernel version. Between the kernel versions of 3.4.0 and 4.7.2, 3.4.0, 3.8.0, and 4.6.2 showed behavioral differences regarding the fsync() system call. The latency of fsync() in kernel 3.4.0 is longer than that of the more-advanced 3.7.10; meanwhile, the characteristics of 3.8.0 enabled the disruption of the Ext4 journaling order, but the ordered defect was solved with 4.6.2.

• KIPS Transactions on Software and Data Engineering
• /
• v.12 no.3
• /
• pp.111-116
• /
• 2023

The WiscKey database, which optimizes overhead by compaction of the LSM tree-based Key-Value database, stores the value in a separate file, and stores only the key and value addresses in the database. Each time an fsync system call function is used to ensure data integrity in the process of storing values. In previously conducted studies, workload performance was reduced by up to 5.8 times as a result of performing the workload without calling the fsync system call function. However, it is difficult to ensure the data integrity of the database without using the fsync system call function. In this paper, to reduce the overhead of the fsync system call function while performing workloads on the WiscKey database, we use NVDIMM caching techniques to ensure data integrity while improving the performance of the WiscKey database.

• JSTS:Journal of Semiconductor Technology and Science
• /
• v.15 no.5
• /
• pp.570-576
• /
• 2015

Existing flash storage devices such as universal flash storage and solid state disk support command queuing to improve storage I/O bandwidth. Command queuing allows multiple read/write requests to be pending in a device queue. Because multi-channel and multi-way architecture of flash storage devices can handle multiple requests simultaneously, command queuing is an indispensable technique for utilizing parallel architecture. However, command queuing can be harmful to the latency of fsync system call, which is critical to application responsiveness. We propose a dynamic queue depth adaptation technique, which reduces the queue depth if user application is expected to send fsync calls. Experiments show that the proposed technique reduces the fsync latency by 79% on average compared to the original scheme.

• The Journal of the Korea Contents Association
• /
• v.19 no.5
• /
• pp.187-193
• /
• 2019

Key-value storage engines are an essential component of growing demand in many computing environments, including social networks, online e-commerce, and cloud services. Recent key-value storage engines offer many features such as transaction, versioning, and replication. In a key-value storage engine, transaction processing provides atomicity through Write-Ahead-Logging (WAL), and a synchronous commit method for transaction processing flushes log data before the transaction completes. According to our observation, flushing log data to persistent storage is a performance bottleneck for key-value storage engines due to the significant overhead of fsync() calls despite the various optimizations of existing systems. In this article, we propose a group synchronization method to improve the performance of the key-value storage engine. We also design and implement a transaction scheduling method to perform other transactions while the system processes fsync() calls. The proposed method is an efficient way to reduce the number of frequent fsync() calls in the synchronous commit while supporting the same level of transaction provided by the existing system. We implement our scheme on the WiredTiger storage engine and our experimental results show that the proposed system improves the performance of key-value workloads over existing systems.

• Journal of KIISE
• /
• v.43 no.11
• /
• pp.1216-1222
• /
• 2016

The advent of large-scale web services has resulted in gradual increase in the amount of data used in those services. These big data are managed efficiently by DBMS such as MySQL and MariaDB, which use InnoDB engine as their storage engine, since InnoDB guarantees ACID and is suitable for handling large-scale data. To improve I/O performance, InnoDB caches data and index of its database through a buffer pool. It also supports multiple buffer pools to mitigate lock contentions. However, the multiple buffer pool scheme leads to the additional data consistency overhead. In this paper, we analyze the overhead of the multiple buffer pool scheme. In our experimental results, although multiple buffer pool scheme mitigates the lock contention by up to 46.3%, throughput of DMBS is significantly degraded by up to 50.6% due to increased disk I/O and fsync calls.

• Journal of KIISE
• /
• v.43 no.4
• /
• pp.411-418
• /
• 2016

In recent times, NAND flash memory has become widely used as secondary storage for computing devices. Accordingly, to take advantage of NAND flash memory, new file systems have been actively studied and proposed. The performance of these file systems is generally measured with benchmark tools. However, since benchmark tools are executed by software simulation methods, many researchers get non-uniform benchmark results depending on the system environments. In this paper, we use Filebench, one of the most popular and representative benchmark tools, to analyze benchmark results and study the reasons why the benchmark result variations occur. Our experimental results show the differences in benchmark results depending on the system environments. In addition, this study substantiates the fact that system performance is affected mainly by background I/O requests and fsync operations.