It's obvious to some of you that disk speed doesn't just depend on a hardware - file systems and kernels also have a lot to say. In this article, we will check how to improve read / write performance of SSD disks on an ext4 file system - especially for small files. I am using Ubuntu 20.04 (I'm still thinking about Fedora 🤔) and my SSD is a Samsung 512GB (SM961).
Be aware that the changes we make here may result in data loss. If you are not sure about that change, please use the operating system with the default configuration. In my case, the disaster recovery of the development environment takes less than 1 hour (all repos on github and cloud data). I have been using this solution for over 1 year now without any issue.
The problem
Some time ago I switched from MacBook Pro (2019) to Dell Precision 7730 (Ubuntu 20.04) and just after a few hours I found that my daily basis code tasks (like Django, Laravel migrations, npm, RDBM, Docker things?!, etc.) took much longer. After days of debugging and worrying about that change, I realized that it was related to write barriers. So if you are familiar with that problem you can stop reading here, but if you want to know more details and see some benchmarks then just enjoy the content.
Solution
It is a simple change, but changes a lot. You need only to add barrier=0 in /etc/fstab my final version looks like this
# /etc/fstab
UUID=f78ac0... / ext4 errors=remount-ro,barrier=0 0Write barriers
Ext4 is a modern file system and the most popular one in the Linux world. By default, Ubuntu 20.04 is using that as a safe choice (we will see what happen with 22.04). Modern file systems are journaling file systems, it means they track changes that have not yet been written to the disk, and in just a few words the write barriers protect your data by confirming the successful write.
The use of nobarrier is also no longer recommended in Red Hat Enterprise Linux documentation because of negligible impact on performance (approximately 3%). There is also very old post from Linus Torvalds posted on 2005 about write barriers or article about ext4 on kernel.org.
Benchmarks
database migrations
For me (as I'm the end user of distro and machine) the most important thing is the time I spend waiting for the task completion. The biggest difference I found was a database migrations time, before it was 342 seconds and after that change it dropped drastically to 16 seconds.
# before
start=$(date +%s) && migration_scripts && end=$(date +%s) && result=$(( end - start ))
echo $result # 342 seconds
# after
start=$(date +%s) && migration_scripts && end=$(date +%s) && result=$(( end - start ))
echo $result # 16 secondsfio
I also made some tests using fio tool, more details about that is on Google Cloud Docs. The results are not very clear
# before
➜ ~ sudo fio --name=write_throughput --directory=$TEST_DIR --numjobs=8 \
--size=10G --time_based --runtime=60s --ramp_time=2s --ioengine=libaio \
--direct=1 --verify=0 --bs=1M --iodepth=64 --rw=write \
--group_reporting=1
# WRITE: bw=1306MiB/s (1370MB/s)
#after
➜ ~ sudo fio --name=write_throughput --directory=$TEST_DIR --numjobs=8 \
--size=10G --time_based --runtime=60s --ramp_time=2s --ioengine=libaio \
--direct=1 --verify=0 --bs=1M --iodepth=64 --rw=write \
--group_reporting=1
# WRITE: bw=1369MiB/s (1436MB/s)Ubuntu disk benchmark
Before
After
