See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/304743738

Benchmarking Performance of EXT4, XFS and BTRFS as Guest File Systems

Under Linux Environment

Conference Paper · June 2016

CITATIONS READS

0 24,863

4 authors:

Dejan Vujičić Dusan Markovic

University of Kragujevac University of Kragujevac
52 PUBLICATIONS   293 CITATIONS    67 PUBLICATIONS   89 CITATIONS   

SEE PROFILE SEE PROFILE

Borislav Djordjevic Siniša Ranđić

University of Belgrade University of Kragujevac
64 PUBLICATIONS   162 CITATIONS    151 PUBLICATIONS   488 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Edge, Fog i Cloud računarstvo - Edge, Fog and Cloud Computing View project

Applications of Wireless Sensor Networks in Agriculture View project

All content following this page was uploaded by Siniša Ranđić on 30 August 2017.

The user has requested enhancement of the downloaded file.

 Benchmarking performance of ext4, xfs, and
btrfs as guest file systems under Linux
environment
Dejan Vujičić, Dušan Marković, Borislav Đorđević, Siniša Ranđić
Abstract—The benchmark results for three most common file
systems under Linux environment, ext4, xfs, and btrfs, used as
guest file systems, were given in this paper. Btrfs is one of the
most popular newly created file systems, and was benchmarked
against ext4 and xfs. These file systems were benchmarked in the
Filebench tool measuring I/O throughput and I/O latency in
emulated file server, web server, and mail server environment.
The results showed that performance of btrfs guest file system is
not the best in the case of existing scenario with ext4 as the base
file system.
Index Terms—benchmark, btrfs, ext4, file system, Linux, xfs.
I. INTRODUCTION
This paper brings benchmarking test of three most popular
file systems under Linux operating system, ext4, xfs, and
btrfs, used as guest file systems on top of the existing ext4 file
system. All of these file systems are based upon B-trees,
slightly modified, to accomplish different aspects of their
appliance. Btrfs is relatively new file system that has been
awarded with much attention in the past several years. One of
the reasons is that btrfs is Copy-On-Write file system,
designed primarily for easy administration and fault tolerance
in large systems.
The benchmarking is done using Filebench tool, which is
one of the most popular benchmarking utilities under Linux
operating system. Filebench measures I/O throughput and I/O
latency under simulated mail server, web server, and file
server environment. The same number of files is used, but
with different number of threads and different size, to
accomplish the results that are similar to those in real life.
The chapters in this paper are organized as follows. The
second chapter brings related work of the authors that have
measured performances of these three file systems, alone, or
together with other relative file systems. The third chapter
describes basic characteristics of these three file systems,
Dejan Vujičič – Faculty of Technical Sciences in Čačak, University of
Kragujevac, Sv. Save 65, 32000 Čačak, Serbia (e-mail:
dejan.vujicic@ftn.kg.ac.rs)
Dušan Marković – Faculty of Agronomy in Čačak, University of
Kragujevac, Cara Dušana 34, 32000 Čačak, Serbia (e-mail:
dusan.markovic@kg.ac.rs)
Borislav Đorđević – Mihajlo Pupin Institute, University of Belgrade,
Volgina 15, 11000 Belgrade, Serbia (e-mail: borislav.djordjevic@pupin.rs)
Siniša Ranđić – Faculty of Technical Sciences in Čačak, University of
Kragujevac, Sv. Save 65, 32000 Čačak, Serbia (e-mail:
sinisa.randjic@ftn.kg.ac.rs)
Proceedings of 3rd International Conference on Electrical, Electronic and Computing Engineering
IcETRAN 2016, Zlatibor, Serbia, June 13 – 16, 2016, ISBN 978-86-7466-618-0
giving special attention to btrfs and its structure. The fourth
chapter brings benchmarking results of these three file
systems that were accomplished under host ext4 file system.
The Filebench tool is used for benchmarking, measuring
performance of I/O throughput and I/O latency in mail server,
web server, and file server simulated environment. The fifth
chapter brings the analysis of the obtained results. The final
chapter denotes concluding remarks.
II. RELATED WORK
Authors [1] compared btrfs with xfs and ext4 on a single
SATA drive with 6 Gbps link. Under the Linux kernel make
tool, btrfs was proven to be slightly better in average seek
count, while ext4 had higher throughput, little less than twice
as much compared to btrfs and xfs. Also, ext4 slightly
outperformed in average I/O operations per second. However,
since this test is meta-data intensive, authors concluded that in
general these file systems are similar in performance.
The same authors [1] performed FFSB (Flexible File
System Benchmark) test, simulating the mail server (it creates
500000 files in 1000 directories with file size varying from 1
KB to 1 MB). This test showed that ext4 had better
throughput in both read and write scenarios, while btrfs was
slightly behind. The worse results were with xfs.
The final test in [1] was about write performance. They
used Tiobench, which was writing to a 2000 MB file with 1,
2, 4, 8, and 16 threads. This test showed that btrfs run fastest
than the other two file systems.
In [2], the ext3, ext4, ReiserFS, jfs, xfs, and btrfs were
tested on three Advanced Format hard disk drives (the older 1
TB Western Digital HDD and the newer 2 TB Seagate and 3
TB Toshiba HDDs). The goal was to benchmark performance
of file systems against the partition alignment. Authors wrote
a script that created fresh file system, and performed several
writes and reads of files that was 365 MB and 451 MB in size.
On the Western Digital disk, btrfs was proven best in reading
performance, while ext4 slightly outperformed in writing
performance. The situation was reversed on the Toshiba
HDD. However, on the Seagate HDD, btrfs was better in both
aspects.
In [3], btrfs and ext4 were tested on a single disk with
several benchmarking tools. Iozone tool showed that btrfs was
better in general for both reading and writing large size files.
Seekwatcher tool showed that btrfs does many more seeks
that ext4. Large file reading and writing gave advantage to
pp. RTI1.3.1-5
btrfs, while ext4 outrun in writing a directory tree. The
computational chemistry test proved ext4 to have higher
throughput and making less I/O operations than btrfs.
Authors [4] performed testing of ext3, ext4, xfs, and btrfs
file systems on single hard disk using multiple benchmark
tools. The goal was to show performances of these file
systems to be used as a cloud storage. Bonnie++ showed that
btrfs was way more supreme in sequential and random writing
to files and files deletion, while the results were almost equal
in the term of files reading. Iozone showed that btrfs and ext4
performed slightly better than xfs and ext3 with large files
operations.
In [5], authors tested ext2, ext3, xfs, btrfs, ReiserFS, and jfs
on a single hard disk in various terms of performance with 1.7
GB and 17.4 GB files. Among the file systems of interest,
ext4 showed better performance in copying large files,
searching and deleting files, and had better average load time.
Btrfs was better in zipping small files, while xfs was better in
searching small files.
III. THE EXT4, XFS, AND BTRFS FILE SYSTEMS
A. Fourth extended file system (ext4)
The ext4 file system is an extension to the ext3 file system
and was released under Linux Kernel 2.6.28 in 2008 [6]. Ext4
can support files up to 16 TB in size, and unlimited number of
sub-directories [7].
The ext4 file system was designed to outperform ext3 in
terms of scalability, performance, and reliability. The ext4 has
the following characteristics [8]:
 Maximum filesystem size of up to 1 EB (Exabyte), due
to extended mapping with 48-bit block numbers.
 Journaling of addresses of modified blocks in the file
system.
 Hashed B-tree (H-tree) is used for organizing and
finding directory entries [9].
 Using of extents (descriptors that represents a range of
contiguous physical blocks) for mapping logical to
physical blocks. A single extent can represent 128 MB
of data.
 Ext4 inode structure can store four extents. For lager
files, the extents map of a file is stored in a constant
depth extent tree.
 Persistent preallocation and reducing of fragmentation
by marking allocated but uninitialized extents.
 Delayed and multiple block allocation by combining
many block allocation requests into a single request.
 Online defragmentation tool (e4defrag), which
performs defragmentation of individual files or the
whole file system.
 Counting of unused inodes and reducing time for fsck
tool.
 Easily detectable corruptions of files by metadata
checksumming.
B. XFS file system
XFS was originally designed at Silicon Graphics, Inc., as a
highly scalable, high-performance file system [10]. XFS is
designed to provide high parallel I/O performance, high
scalability of I/O threads and high file system bandwidth [11].
XFS has the following main characteristics [11]:
 Maximum file system size and maximum file size of
nearly 8 EB.
 Journaling for metadata operations.
 Partitioning into allocation groups (fixed size virtual
storage regions).
 Based on extents, where file blocks can have extents of
variable length.
 Delayed allocation for minimizing fragmentation and
increasing performance.
 Implemented direct I/O for high throughput and non-
cached I/O for DMA devices.
 Snapshot capabilities.
 Support for user, group, and project disk quotas on
block and inode.
C. Btrfs file system
Btrfs is a copy-on-write (COW) file system based on B-
trees, introduces in 2007 [1]. It was designed to improve
scalability of large storage subsystems [12], with the
capabilities of fault tolerance, repair and easy administration
[13].
The btrfs has the following advanced capabilities [13]:
 Based on extents.
 Maximum file size of 16 EB.
 Dynamic inode allocation.
 Packing of small files and directories indexing in
space-efficient manner.
 Support for snapshots, subvolumes, and compression.
 Flash storage optimizations.
 Background based fixing errors on redundant files.
 Online defragmentation, offline file system check.
 Support for quotas on subvolume level.
 Built-in RAID functionality and checksums [14].
 File system is a forest of B-trees, with COW as the
update method [1].
The sample organization of btrfs file system is shown in
Fig. 1.
Fig. 1. An organization of btrfs file system
Btrfs is based on special kind of B-trees called B+ trees.
They use basic B-tree construction, but have top-down update
procedure, remove leaf linking, and use lazy reference- Linux capabilities by enabling virtualization [17]. Managing
counting for space management [1]. The COW technique of KVM based virtual machine is carried out by Virt-
enables writing modified blocks to a new location on disk, Manager, an application that supports creating, starting,
thus preventing overwriting of old data. The additional editing and stopping virtual machines.
contributions of COW are data protection and improving
performance. The COW system uses transaction mechanism TABLE II
HARD DISK DRIVE SPECIFICATION
to accumulate updates in memory and write them all at once
to the new blocks on the disk [15].
Model Cheetah 15K.7, 3 x 600GB, 3.5"
IV. BENCHMARKING SETUP AND RESULTS Capacity 3 x 600GB
Filebench is flexible file system and storage benchmark that Available Capacity 1.1TB (3 x 600GB in RAID5)
could use variety of workloads to emulate complex Interface SAS
applications [16]. Filebench is popular framework because it Transfer Rate to Host 6Gb/s
contains several predefined macro workloads such as File Cache 16MB
server, Web server, and Mail server, which could be used to
benchmarking file systems with this single tool. The power of Rotation Speed 15000 RPM
Filebench is not only from their included workloads but also Average Latency 2.0ms
from using its extensive language, Workload Model Language Seek Time Average
(WML), which could be used to specify application behavior by 3.4/3.9ms
Read/Write
encoding appropriate new workloads.
For this article three Filebench workloads were used to On top of existing host file system, virtual machine was
benchmarking file systems and those are: File server, Web created with nested file systems on which Debian Linux
server and Mail server, as very popular workloads among operating system was installed with kernel Linux 3.16.0-4-
users. These workloads were design according to real server amd64. For virtual machine, 512MB of memory was reserved
behavior and files that produces on a file system. and one processor core. Nested file system has one root
partitions and additional three partitions, which are ext4, xfs,
TABLE I
HARDWARE SPECIFICATION OF THE HOST SYSTEM and btrfs, with 10GB capacity of each partition.
Combination of nested file systems was tested and describe
Hardware Specification in paper [18], but at that time btrfs file system was not taken
into consideration. Our case involves running virtual machine
Memory (RAM) 16GB
on ext4 as host file system. Under created virtual machine, on
Intel Xeon (R) CPU E5-2609 v2
CPU Model top of ext4, combination of ext4, xfs and btrfs was used as
@ 2.50GHz x 8
nested file system partitions. The aim was to test these
Number of CPU Cores 8
partitions on top of ext4 and compare performance of nested
Hard Disk Drive Cheetah 15K.7, 3 x 600GB, 3.5" btrfs file system partition with xfs and ext4.
CentOS 7.2.1511 Under running virtual machine file system partitions ext4,
Operating System kernel – Linux 3.10.0- xfs and btrfs were selected and tested with workloads for
229.20.1.el7. x86_64 services such as file server, web server, and mail server.
Simulation of these three services was benchmarked by
Testing was performed on hardware system with Filebench workloads whose main parameters are shown in
specification presented in Table I. This computer has three Table III.
hard disks with capacity of 600GB each and their
specification is shown in Table II. TABLE III
The computer has hard disk configuration setup as RAID 5. PARAMETERS FOR FILEBENCH WORKLOADS
According to this, parity was stripped across all of disks and
available storage space is 1/3 of overall capacity which means Number Number
Services File size I/O size
that maximum of 1.2GB could be used for storage space at of files of threads
server system. Partitions of this file system were formatted as File server 70000 50 128KB 16KB-1MB
ext4 and CentOS 7 Linux was running as host operating Web server 70000 100 16KB 16KB-1MB
system. This is the configuration of server on which guest file Mail server 70000 16 16KB 16KB-1MB
systems are created and tested. On top of the base file system,
server resources could be used for setting and running virtual According to the parameters form Table III working set
machines. The computer with installed CentOS 7 operating size is defined to be larger than page cache in the virtual
system has kernel-3.10.0-229.20.1.el7. x86_64 and uses KVM machine. Each of the workloads was running on appropriate
for virtualization. KVM represents virtualization software that partition and results are shown in Table IV for I/O throughput,
provides ability to run a guest operating system as a virtual and their comparison is shown in Fig. 2.
platform. KVM is added as a kernel module that could extend
 TABLE IV I/O latency for used workloads is presented in Table V and
I/O THROUGHPUT
Fig. 4. These results are also depending on the guest file
system that is used for virtual machine on top ext4 base
I/O Throughput (mb/s) system.
Services
ext4 xfs btrfs
File server 17.5 7.4 8.8 V. ANALYSIS OF THE RESULTS
Web server 24.0 10.3 11.9 Although btrfs has capability to become default file system
for many Linux distributions [19], its usage as nested file
Mail server 3.2 1.8 1.0
system depends on server hard disk base configuration.
Existing server has its own main functionality but its
resources are not fully utilized. To take advantage of already
running server, virtual machine was created on top of ext4.
Tests were running with file server workloads and results
show that the highest value of I/O throughput is in the case
when guest file system is also ext4. Values for xfs and btrfs
were approximately twice less than for ext4, but btrfs has
some better value then xfs. There was also similar ration
between results in the case when web server workloads are
used for testing. With mail server workloads benchmark result
on btrfs partition had lower value then for xfs (Fig. 2).
During selection of nested file system type there should be
taken into account benefits of btrfs on one side and its I/O
Fig. 2. I/O throughput using file server, web server and mail server throughput on other side. Another solution for new hardware
workloads configuration would be using btrfs as base file system type
and testing performance of guest file system type that would
Considering the hardware configuration of the server, ext4 be selected for virtual machine.
as nested partition has the highest value for I/O throughput.
This is case for testing with fileserver workloads and also for VI. CONCLUSION
web server and mail server workloads. On the other hand,
Server that is already running and has its main functions
btrfs has some better value in regard to xfs for benchmarking
could be additionally utilized by creating virtual machines. On
with file server and web server workloads but in the case of
top of existing ext4 file system, guest file system ext4, xfs,
mail server testing values are worse compared to xfs partition
and btrfs were defined and tested with Filebench workloads.
(Fig. 2).
Presented results show performance of guest file systems in
TABLE V
the case of specific scenario with the server that already has
I/O LATENCY ext4 as base file system. In general, testing results could vary
depending on combination of host and guest operating
I/O Latency (ms) systems, host file system, and resource occupation of the host.
Services However, in this case server resources were not fully
ext4 xfs btrfs
utilized and main host function is not used during testing.
File server 183.0 459.1 360.7 Thus, the results were obtained for specific server settings
Web server 49.2 113.1 86.0 running on operating system with kernel version given in this
Mail server 55.3 101.1 180.3 paper.
Presented results could be used when making decision for
selecting appropriate guest file system on existing ext4 host
file system. Beside its benefits as new file system, btrfs is not
the best solution in the given case, on ext4 as base, where
throughput performance was taking into account.
Despite all the advantages that btrfs has, its appliance as
guest file system did not give the best performance. I/O
throughput for btrfs while testing with file server and web
server workloads has for a little better value than for xfs, but
not so good value as ext4. Further research could be related to
setting btrfs as host file system and checking performance for
different used guest file systems.

Fig. 3. I/O Latency using file server, web server, and mail server workloads
ACKNOWLEDGMENT [9] Ext4 Disk Layout, Available at:
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout (10.4.2016)
The work presented in this paper was funded by grant [10] Xfs, Red Hat Enterprise Linux 6 Storage Administration Guide,
TR32043 for the period 2011-2016, by the Ministry of Available at:
https://access.redhat.com/documentation/en-
Education, Science, and Technological Development of the US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/c
Republic of Serbia. h-xfs.html (10.4.2016)
[11] All About xfs, Oracle, Available at:
https://docs.oracle.com/cd/E37670_01/E37355/html/ol_about_xfs.html
REFERENCES
(10.4.2016)
[1] O. Rodeh, J. Bacik, and C. Mason, “The Linux B-Tree Filesystem,” [12] All About btrfs, Oracle, Available at:
Trans. Storage 9, vol. 3, article 9, Aug. 2013 https://docs.oracle.com/cd/E37670_01/E37355/html/ol_about_btrfs.html
[2] R. Smith, “Linux on 4KB-sector disks: Practical advice,”, Available at: (10.4.2016)
http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/ [13] Btrfs, Available at: https://btrfs.wiki.kernel.org/index.php/Main_Page
(10.4.2016) (10.4.2016)
[3] M. T. Kebede, “Performance Comparison of Btrfs and Ext4 [14] Btrfs, Getting Started, Oracle, Available at:
Filesystems,” Master Thesis, Network and System Administration Oslo http://www.oracle.com/technetwork/articles/servers-storage-
And Akersus University College Of Applied Science, 2012 admin/gettingstarted-btrfs-1695246.html (10.4.2016)
[4] D. Groenewegen and P. Lange, “Performance of remote storage for [15] J. Chen, J. Wang, Z. Tan, and C. Xie, “Recursive Updates in Copy-on-
clouds,” University of Amsterdam System & Network Engineering, write File Systems - Modeling and Analysis,” Journal of Computers,
2011 vol. 9, no. 10, pp. 2342-2351, Oct 2014
[5] A. Vladimirovich Ostroukh and A. Salniy, “Research of Performance [16] Filebench, Available at:
Linux Kernel File Systems,” International Journal of Advanced Studies http://filebench.sourceforge.net/wiki/index.php/Filebench (05.4.2016)
(iJAS), vol. 5, no 2, pp. 12-17, 2015 [17] T. Hirt, “KVM - The Kernel-Based virtual machine,” Red Hat Inc.,
[6] T. Leemhius, “Higher and further: The innovations of Linux 2.6.28,” Available at: http://www.cs.hs-rm.de/~linn/fachsem0910/hirt/KVM.pdf,
Available online: http://www.h-online.com/open/features/Kernel-Log- 2010
Higher-and-Further-The-innovations-of-Linux-2-6-28-746519.html [18] D. Le, H. Huang, and H. Wang1, “Understanding Performance
(10.4.2016) Implications of Nested File Systems,” FAST'12 Proceedings of the 10th
[7] Ext4, Red Hat Enterprise Linux 6 Storage Administration Guide, USENIX conference on File and Storage Technologies, San Jose, CA,
Available at: https://access.redhat.com/documentation/en- USA, pp. 1-13, February 14-17, 2012
US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/c [19] J. Kljajić, N. Bogdanović, M. Nankovski, M. Tončev, and B.
h-ext4.html (10.4.2016) Djordjević, “Performance Analysis of 64-bit ext4, xfs and btrfs
[8] A. Mathor, M. Cao, S.Bhattacharya, A. Dilger, A. Tomas, and L. Vivier, filesystems on the Solid-State disk technology,” INFOTEH-JAHORINA
“The new ext4 filesystem: current status and future plans,” in vol. 15, pp. 563-566, March 2016
Proceedings of the 2007 Ottawa Linux Symposium, vol. 2, pp. 21-33,
2007

View publication stats