If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
Linux 2.6.39: XFS Speeds-Up, EXT4 & Btrfs Unchanged
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
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.
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).
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?
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.
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
Linux 2.6.39: XFS Speeds-Up, EXT4 & Btrfs Unchanged
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.
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
Leave a comment: