Testing BTRFS – Performance comparison on a high performance SSD (BTRfs vs Ext4)

Hi,
Today I was reading about btrfs and as never used it before I thought in giving it a try.
On my laptop I have a ssd with 256GB, there I created 2 LVM2 volumes to use and test btrfs.
It’s not the ideal solution because there’s a LVM layer but I’m not in the mood for backup,erasing,installing,erasing and installing. So the tests I’m going to do are just on the FS itself, not on all the layers that btrfs supports. A good thing in using a ssd card is that the access time is equal for all the block device and the data position on the block device is not accountable, so this is a very good opportunity to have measurements both on ext4 and btrfs.
Here’s the benchmark architecture, tools and setup:

Kernel:

Linux MartiniMan-LAP 2.6.38-31-desktop #1 SMP PREEMPT 2011-04-06 09:01:38 +0200 x86_64 x86_64 x86_64 GNU/Linux

LVM lv creation command:

lvcreate -L 20G -n TestingBTRfs /dev/mapper/system
lvcreate -L 20G -n TestingExt4fs /dev/mapper/system

LVM lvdisplay output:

--- Logical volume ---
LV Name /dev/system/TestingBTRfs
VG Name system
LV UUID zBYf0d-metk-VC9U-YkjE-z1Ts-NMLb-HzYmrJ
LV Write Access read/write
LV Status available
LV Size 20.00 GiB
Current LE 5120
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:3

--- Logical volume ---
LV Name /dev/system/TestingExt4fs
VG Name system
LV UUID FJEfiv-Hs9W-zGuV-sJIo-3INN-gh52-YgmsVl
LV Write Access read/write
LV Status available
LV Size 20.00 GiB
Current LE 5120
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:4

FS creation command:

mkfs.ext4 /dev/system/TestingExt4fs
mkfs.btrfs /dev/system/TestingBTRfs

Processor:

model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz

HardDrive:

Device Model: SAMSUNG MMDOE56G5MXP-0VB

Mount command (as you can see I didn’t do any optimizations, noatime, etc):

/dev/mapper/system-TestingBTRfs on /mnt/btrf type btrfs (rw)
/dev/mapper/system-TestingExt4fs on /mnt/ext4 type ext4 (rw)

Test software:

'Iozone' Filesystem Benchmark Program

Version $Revision: 3.373 $
Compiled for 64 bit mode.

Command line for the tests:
Command line used:

 ./iozone -Ra -r4k -r8k -r16k -r32k -r64k -r128 -r1024 -r4096k -r16384k -s1g

This command was used in the btrfs and the ext4 volumes.
The options mean:
-R excel/

office compatible format.
-a auto test
-r the record size (you can see I used several (4k,8k…))
-s size of test file (I used 1GB)

Here’s the test results:

And the charts (The scale is logarithmic):

(you may download the data here: [download id=”1″])

Conclusions

As you can see on the charts for sequential reading/writing there’s a performance gain  in BTRfs with the smaller record sizes but the inverse is also true, EXT4 has more performance on larger record sizes.

If you look to the random data access while reading or writing you’ll see that EXT4 is far faster that BTRfs, and this is according to my daily usage pattern would be 70% of the access to my hard drive. To be sincere I’m a bit surprised on such a difference. I know I didn’t tune any of the file systems and the purpose of this benchmark is not having to, just playing with the defaults as most of the installations out there.

Another conclusion that is really simple to understand is that bigger record sizes mean best performance.

For now I think I’ll stick to EXT4 and LVM, who knows if I’ll sometime soon I’ll change to BTRFS, I’ll let it grow and advise you to do the same.

Cheers,

Pedro Oliveira

Hard reset on linux command line.

Linux is not Windows and if reboot fail you usually still connect by SSH and do something. This commands will show you how to remotely hard reboot machine.

Hard reboot mean that shutdown scripts will not run and machine reboot immediately without syncing hard disk drives, shutdown applications etc, it’s like hitting the reset button on your server.

 

echo 1 > /proc/sys/kernel/sysrq

echo b > /proc/sysrq-trigger

This commands enable sysrq and after this calls fast reboot. If you want to force shutdown machine try this.
Force shutdown

 

echo 1 > /proc/sys/kernel/sysrq

echo o > /proc/sysrq-trigger

This came handy, when I had a server that had some IO error and it can no longer read from disk, only few cached binaries into memory kept it running (kernel, SSHD, bash), I could still access the machine via SSH but can no longer do anything, forcing the reboot as mentioned above was my only resort, and it worked like charm…

Kernel 2.6.31 is out and rocking!

This weekend I’ve had some free time so I tested a new kernel on my suse 11.1 x86_64 system. I’ve been a beta tester for the kernel for some time and I was eager to test the final version.

There are plenty new features, the one I enjoy more are probably on the filesystem area but there is plenty to choose.

This version adds USB 3.0 support, a equivalent of FUSE for character devices used for proxying OSS sound to ALSA, some memory management changes that improve interactivity in desktops, readahead improvements, ATI Radeon Modesetting support, support for Intel’s Wireless Multicomm 3200 Wifi devices, kernel support and a userspace tool for performance counters, gcov support, a memory checker for unitialized memory, a memory leak detector, a reimplementation of inotify and dnotify on top of a new filesystem notification infrastructure, btrfs improvements, support for the IEEE 802.15.4 network standard, IPv4 over Firewire, many new drivers, small improvements and fixes.

You may see the hole list here:

http://kernelnewbies.org/Linux_2_6_31

I still didn’t do extensive testing but so far so good ;), although my kde4.3  seams to lag a bit, I’m not sure if this is from the new kernel or the changes I’ve done within KDE itself.

On the other end with server machines it works perfectly, i’m doing stress tests on two virtual servers and memory usage / IO times / CPU usage.

On the test i’m using two opensuse 11.1 x86_64, one as 2.6.27 kernel version and the other 2.6.31, same amount of memory and 2 cpu each on the same host. Hope to have some more data in a few days and then post the results (cacti graphs) here if they are relevant.

So, what are you waiting for… TRY IT

Cheers

Pedro Oliveira

Click to access the login or register cheese