Linux 2.6.39: XFS Speeds-Up, EXT4 & Btrfs Unchanged

[phoronix]

Phoronix: Linux 2.6.39: XFS Speeds-Up, EXT4 & Btrfs Unchanged

While we have already delivered a number of benchmarks from the Linux 2.6.39 kernel, surprisingly we have not yet published any new file-system benchmarks from this latest stable Linux kernel release. Fortunately, that has changed today with a fresh round of Btrfs, EXT4, and XFS file-system benchmarks on the Linux 2.6.39 kernel and compared to the preceding 2.6.38 and 2.6.37 kernel releases.

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

[yesterday]

Normally people (like myself) complain if they are unhappy with the article.

So, this time I'd like to say that this was a good article. You provided some useful explanations, and also linked to the optimizations at the end which was informative

Thanks!

[ean5533]

Normally people (like myself) complain if they are unhappy with the article.

So, this time I'd like to say that this was a good article. You provided some useful explanations, and also linked to the optimizations at the end which was informative

Thanks!

Amazing. This is the first time I've ever seen a comment on Phoronix saying they liked an article. I'm so used to seeing nothing pure hatred in every article comment. Maybe there is hope after all.

[flammon]

I have a hexacore now so I'm interested in a filesystem that makes good use of multiple cores. Would btrfs be much faster with compression enabled if a system had many cores? Could the compression/decompression be done by a GPU?

[squirrl]

Remember the Commodore VIC 20
http://oldcomputers.net/vic20.html

For some reason I was sitting here reading this excellent article and was reminded of the VIC 20.

[Veerappan]

I have a hexacore now so I'm interested in a filesystem that makes good use of multiple cores. Would btrfs be much faster with compression enabled if a system had many cores? Could the compression/decompression be done by a GPU?

It's possible that the compression could be offloaded to another core(s) or a GPU, but compression is often a fairly serial process, so depending on the algorithm, you'd probably not get much of a speedup.

Also, for the small block sizes being compressed, you'd probably not benefit from GPU compression/decompression as the round trip to the GPU and the computation startup/finish costs would probably exceed any time benefit from the parallelism you might be able to extract.

Offloading the compression/decompression to a separate thread on the CPU might be possible, and that's where I'd probably start poking around (if they're not already doing this).

[danny.archer]

JFS is omitted from the comparison again
What is the reason for this? Isn't it as popular as XFS?

[baryluk]

Wow, really good and specific article. Thankks.

Also congratulations to xfs developers for improving xfs so much

[deanjo]

JFS is omitted from the comparison again
What is the reason for this? Isn't it as popular as XFS?

JFS is a dieing filesystem. Even IBM isn't interested in maintaining it anymore and the one IBM employee that is more or less keeping an eye on it ("very part time") to fix bugs recommends not using it for production environments.

[danny.archer]

JFS is a dieing filesystem. Even IBM isn't interested in maintaining it anymore and the one IBM employee that is more or less keeping an eye on it ("very part time") to fix bugs recommends not using it for production environments.

damn, that's too bad, I'm quite fond of JFS. I've just switched to a new hard drive and all the partitions are JFS, previous hard drive had also XFS. I've managed to avoid EXT3&4

*sigh*