F2FS 파일 시스템의 fsync() 성능 저하 요인 분석

Abstract

본 논문은 UNUX 운영체제에서 사용되는 로그 구조 파일 시스템, F2FS의 fsync() 성능의 분석을 위해 작성되었다. 파일 시스템 (혹은 데이터베이스)은 데이터의 일관성을 유지하기 위해 저널링 (혹은 로깅) 메커니즘을 이용한다. 만약 정전 등의 사태로 갑작스럽게 스토리지에 전원 공급이 중단될 경우, 저널링 파일 시스템은 저널링을 통해 저널 영역에 기록했던 Backup 데이터를 이용하여 리커버리 동작을 수행한다. 그런데 파일 시스템이 저널 영역에 기록된 데이터를 무조건적으로 복구하게 되면 불완전하게 기록된 데이터도 복구될 가능성이 있다. 그래서 파일 시스템이 정상적으로 저널링 동작을 처리 하기 위해서는 스토리지에 기록되는 입출력 쓰기의 순서가 보장되어야 한다. fsync()는 In-memory 상의 수정사항을 스토리지에 영속적으로 기록해주기 위해 사용하는 플러시 명령을 통해 입출력 요청의 순서를 보장하게 된다. 입출력 요청의 순서 보장을 위해 플러시 명령을 사용할 때, fsync()는 후속 입출력 요청의 처리를 지연시키며 결과적으로 fsync()가 전체 입출력 처리 과정에서 큰 병목으로 작용하게 된다. 이러한 이유로 현재까지 fsync()의 성능을 향상시키기 위한 다양한 시도가 있었으며 그것들 중 몇몇 기법들은 실제로 fsync()의 성능을 효과적으로 향상시키는데 기여하였다. 두 기법 (F2FS, 슈퍼 캐퍼시터가 설치된 SSD)은 fsync()의 성능을 향상시키는 대표적인 기법들이다. 그러나, 우리는 fsync()의 성능을 향상시키기 위한 목적으로 두 기법을 같이 적용하였을 때 fsync()의 처리에 큰 성능 저하가 발생하게 되는 것을 확인하였다. 우리는 이러한 성능 저하의 원인을 다양한 실험을 통해 분석하였으며 결과적으로 해당 문제의 원인이 free node IDs에 대한 탐색 동작에 의한 것임을 확인하였다. 또한, 우리는 free node IDs의 탐색에 의한 성능 저하가 플러시 명령에 의해 발생하는 성능 저하가 줄어들게 될수록 증가하게 되는 것을 증명하였다. 실험 결과에 따르면 PC에서 Varmail (fsync() 기반 워크로드)을 수행하였을 때, F2FS의 성능은 워크로드의 실행 시간이 길어짐에 따라 지속적으로 평균 입출력 성능이 감소하게 된다. 결과적으로 Varmail 워크로드 수행 초기에 EXT4 대비 1.06배 높은 성능을 보이던 F2FS 성능은 워크로드 수행 후기에 EXT4 대비 0.67배 낮은 성능을 보이게 된다. 최종적으로, 본 논문에서는 앞서 분석한 성능 저하 요인을 토대로 F2FS 파일 시스템 에서 발생하는 fsync()의 성능 저하 문제를 해결하기 위한 방법들을 제시하였다.; This work is dedicated to analyze the performance of fsync() system call in F2FS, which is the log-structured filesystem used in UNIX operating systems. For the consistency of the data, the filesystem (or database) uses the journaling (or logging) mechanism. If the system crash occurs, the filesystem performs the recovery operation to use the backup data stored through journaling. For the filesystem performs the journaling without any problems, it is important to guarantee the order of write requests being written into the storage device. fsync() guarantees the order of the write requests by the synchronization technique, FLUSH command. When using the FLUSH command to guarantee the order of the write requests, the fsync() system call delays the succeeding I/O requests. There have been the several attempts to increases the performance of fsync(), and some of them actually contribute to improving the performance of fsync(). Among these attempts, two approaches (F2FS and Supercap-SSD) contribute to decrease of the fsync() overhead. However, we discovered that the extremely huge bottleneck occurs in the process of fsync() when using these two techniques. We identified the cause of this problem is the scanning overhead for the free node IDs, and digitalized the effect of the fsync() performance degradation. Furthermore, we proved that the scanning overhead in fsync() of F2FS decreases the I/O performance if the overhead at the FLUSH command diminishes. In the experiment, when performing Varmail (fsync()intensive workload) in PC Server, the performance of F2FS decreases continuously on runtime of Varamil. Consequently, at the beginning of the workload, the performance of F2FS is 1.06X against EXT4, but is 0.67X against EXT4 in the end of the workload. Finally, we proposed the solution for the fsync() performance degradation.