The Linux 2.6.37 Kernel With EXT4 & Btrfs

[phoronix]

Phoronix: The Linux 2.6.37 Kernel With EXT4 & Btrfs

Now that the Linux 2.6.37 kernel merge window is closed and this next major release is in the middle of its development cycle, we have new benchmarks to publish looking at the file-system performance of Btrfs and EXT4 compared to earlier releases. The Linux file-system performance is under constant evolution as shown by our five years of Linux kernel benchmarks and more recent file-system-focused articles such as looking at EXT4 and Btrfs regressions in Linux 2.6.36, solid-state drive Linux benchmarks, and even ZFS-FUSE benchmarks, among other similar articles.

http://www.phoronix.com/vr.php?view=15438

[jbrown96]

Is it possible to ever get any analysis?

[FireBurn]

Is it possible to ever get any analysis?

Nope, just lots of graphs with text underneath describing the graphs for the visually impaired - clearly for the users of Festival

[loonyphoenix]

I don't read the text anyway. The only thing I was interested in was in the beginning, where the testing system was described. The rest I can analyze myself.

[DragonSA]

Hi Phoronix,

I was wondering how you setup your test environment when running filesystem tests. I assume you simple reformat the partition for each test, thus allowing the test to start in a clean, consistent environment.

Although that method should produce the most consistent results it does not take into account normal usage of the filesystem. For example, on my computer my /usr partition is about 16G and usage is at 50%. Every few months I basically rewrite all the data to that partition. Resulting from this usage I expect there to be a fairly high amount of fragmentation of files.

In the above situation it is unlikely that the filesystem will find continuous space for big files and for there to be a reduction in performance. At Anandtech a similar principle applied to SSDs resulting in a performance degradation between 40% to 95%.

The Anandtech article is at:
http://www.anandtech.com/show/2738
with the comparison of performance:
http://www.anandtech.com/show/2738/13

Would it be possible to test filesystems that are at various levels of use (i.e. 50%-90%) after multiples of data being written to them (i.e. on a 20G drive extract FreeBSD sources 40x [sources are ~0.5G], and removing old sources when usage exceeds given level, i.e. simulate normal usage, wear and tear).

Regards

[Ansla]

I don't know how popular RAID is for most readers of Phoronix, but for me "Desktop performance" means RAID5 with 3-4 HDDs, so I would be more interested in seeing how various filesystems / kernel versions scale on this kind of a setup.

[R3MF]

Given that opensuse 11.4 is almost certain to ship with 2.6.37, is it likely that BTRFS will be a fefault install option for this distro release?

Is it stable/fast enough to be included in the installer as a selectable (non warning) option?

cheers

[DeepDayze]

Given that opensuse 11.4 is almost certain to ship with 2.6.37, is it likely that BTRFS will be a fefault install option for this distro release?

Is it stable/fast enough to be included in the installer as a selectable (non warning) option?

cheers

You might have to wait till 2.6.38 I presume to ensure that it is indeed stable enough to be used as a selectable default install option.

In my own opinion I'd like to have an ENTIRE root partition as btrfs with /boot on / though, so may have to wait longer till even GRUB can actually boot directly from btrfs filesystems. Ext4 is fast catching up in performance so then you'd have some great filesystem choices :^)

[R3MF]

cheers.

opensuse split boot and home into different partitions, does this make it more likely they'd allow btrfs as a non-warning option?

[fiete]

I was wondering how you setup your test environment when running filesystem tests. I assume you simple reformat the partition for each test, thus allowing the test to start in a clean, consistent environment.

Although that method should produce the most consistent results it does not take into account normal usage of the filesystem. For example, on my computer my /usr partition is about 16G and usage is at 50%. Every few months I basically rewrite all the data to that partition. Resulting from this usage I expect there to be a fairly high amount of fragmentation of files.

In the above situation it is unlikely that the filesystem will find continuous space for big files and for there to be a reduction in performance.Regards

Without taking this into account these kind of "benchmarks" are completely useless nonsense.