Ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

Question

I'm a linux noob.
Going to install Archlinux to new laptop Inspiron 1520
Right now playing with Archlinux on vmware.
I want my laptop be fast, and of course choosing right FS is important in this regard.
Let me sum up all i read so far about different FS.
ext3 vs XFS, JFS, ReiserFS:
- ext3 is most stable, most supported. But also slowest.
- XFS, JFS, Reiser are much faster, but have stability and or support problems.
- ext3 with dir_index is fast, almost as fast as others.
- noatime,nodiratime considerably improve performance of all these FS
So here are my questions.
1. Will ext3 + dir_index + noatime,nodiratime be up to the par with XFS,JFS ?
2. Does disr_index enabled by default on latest Arch or do I have to enable it manually ?
3. What other advantages besides speed JFS,XFS have comparing to ext3 ?

Answer 1

lucke wrote:Fragmentation can be an issue. <snip>....<snip>s impact on performance.
Yes indeed fragmentation can cause a significant penalty in performance, especially if you are copying large, very fragmented files. But for a desktop system people usually deal with smaller files than ones downloaded in large torrents; at least that was my impression for my previous post. The thing about XFS being designed as it is, is that it doesn't handle fragmentation of large files well. Basically, the extensive use it makes of B+ trees make it particularly cpu intensive for working with reads that are non-continuous and hence is particularly hurt when copying highly fragmented, large files. This isn't quite as pronounced in JFS (but the performance hit is there) because it's cpu usage isn't as high as XFS; and it's algorithms are more optimized for working with smaller continuous reads than XFS (to my understanding). This is probably the main reason why XFS has a defragmentor and JFS does not.
One thing that fragmentation of a JFS filesystem will have a major effect on is performance of a VMware virtual machine whose image is highly fragmented on JFS. I mentioned this in the wiki article. If you use VMware with a growing image, I recommend somewhat regular defragmenting of the JFS partition, otherwise the VM will be significantly impeded. I imagine this situation is true for other file systems other than JFS. Also, if you torrent frequently with large files, then I would suggest regular JFS defragmenting in this scenario as well.
Gullible Jones wrote:Re JFS data loss: bug reports have been filed. See here and here.
The first report is most likely due to the fact that JFS journals metadata only. This is also the case with XFS, Reiser, and ext3 (with the popular journal=writeback implementation). Caching data losses like the first bug report seems to describe what has been known to happen with other file systems on linux and not JFS. Nonetheless, JFS has never hidden the fact that it journals metadata only as journaling both metadata and actual file data incurs a big performance hit.
The second bug report could easily be a hardware failure. Indeed with both the log and no inodes being dumped to the lost+found directory, I would not jump to judgment that this was necessarily a JFS issue as that would imply JFS failing in SEVERAL different places. It is more likely that the issue was one with hardware.
As I said before, neither one of these show that JFS conclusively looses files in its own right. If you really require journaling of both metadata and file data, then ext3 is the only option for linux (with no journaling /etc/fstab optimizations); JFS and other journaling file systems don't do this as it significantly reduces performance.
Anyway, I am done going on about this; if people are hellbent on believing JFS looses files, so be it. Personally, I have never had a data loss issue with JFS despite years of use and abuse in the spectrum of possible hardware and software configurations.
Last edited by PDExperiment626 (2007-12-29 16:20:36)