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

vagif · 2007-12-27 22:53:37

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 ?

oli · 2007-12-27 23:19:04

I'm using ext3 with dir index and full journal, this is the most reliable solution you can get and I don't have any performance problems.

Read this first:

http://www-128.ibm.com/developerworks/l … l-fs8.html

lucke · 2007-12-27 23:31:28

Honestly, ext3 isn't that much slower than others, sometimes it can be faster. Things also change a bit between different kernel releases. Lots depends on hardware and usage pattern too. With any filesystem you can have into reliability problems.

I have changed my root filesystem on my desktop countless times, now I have settled with JFS. It is apparently a good choice for a laptop too, because it is probably the least CPU demanding of Linux filesystems. For partitions with bigger files (like my desktop's and server's /home), I'm a great fan of XFS - mostly due to its superior fragmentation handling and online defrag tool. It handles bigger files really well, but is rather inferior to other filesystems when handling lots of small files.

I don't think dir_index is enabled by default - in all fairness, it's not a win-win situation, it speeds some operations, but allegedly slows others.

From my experience, situation with FSes is quite fluid and it's difficult to choose one ;-)

ibendiben · 2007-12-27 23:34:15

ext3 - Essentially the ext2 system, but with journaling support. Generally perceived as slightly slower than ext2 and other filesystems, but extremely stable and the most widely used, supported and developed GNU/Linux FS.
ReiserFS - Hans Reiser's high-performance journaling FS uses a very interesting method of data throughput. ReiserFS is fast, especially when dealing with many small files. ReiserFS is very slow at mounting. Quite well established and stable. ReiserFS isn't actively developed at this time (Reiser4 is the new Reiser filesystem).
JFS - IBM's Journaling FS. JFS is very fast and uses the least CPU processing power of any filesystem. Very fast at mounting. It has been reported on the JFS mailing-list that it could suffer from fragmentation problems.
XFS - Very fast journaling filesystem which is best suited for large files, while it is slower (but still quite fast) with small files. Very fast at mounting.

I'd say ext3, I tried ReiseFS but it slows down boot time considerably.

vagif · 2007-12-27 23:46:13

lucke wrote:

I don't think dir_index is enabled by default - in all fairness, it's not a win-win situation, it speeds some operations, but allegedly slows others.

Thanks for clearing that up.
What are disadvantages of dir_index ?
If it is just the additional space on HD, I can live with that.

lucke wrote:

I have settled with JFS. It is apparently a good choice for a laptop too, because it is probably the least CPU demanding of Linux filesystems.

I'm leaning towards JFS so far. I have only 1 nagging issue.
I heard that JFS is abandoned by IBM, and is not supported on some linux distros (not a problem for me). But the question is with support.
I'm afraid that over the time it will fall behind and will be excluded from kernel.

Misfit138 · 2007-12-28 00:15:18

Well, to say that JFS was 'abandoned' by IBM is not really the whole story. It was made open source by IBM as of 1999, and is still actively developed. I use JFS on my laptops, since my laptop CPU's tend to be older PIII's, at ~1Ghz. JFS typically uses less CPU resources than other filesystems.
http://jfs.sourceforge.net/

Last edited by Misfit138 (2007-12-28 00:24:58)

nightmorph · 2007-12-28 02:05:18

Actually, dir_index should be enabled by default, as should other performance-enhancing options; check your config file. You shouldn't have to explicitly turn on anything; just adjust /etc/fstab with options like noatime where necessary.

Look in /etc/mke2fs.conf. This is from a vanilla, unmodified install from source. Should be good for both Arch and Gentoo actually (yes, I dual-boot):

[defaults]
        base_features = sparse_super,filetype,resize_inode,dir_index
        blocksize = 4096
        inode_ratio = 8192

We got a bug about this in Gentoo awhile back; that's when I looked this stuff up.

As far as support goes, as much as I hate to say it, you'd do better to worry about support dying for ReiserFS than for JFS. At least IBM is still a viable company actively doing stuff for Linux. Though I use ReiserFS on both my laptop and desktop, development for ReiserFS is much more likely to stagnate quicker (or at all, or even die entirely), compared to any of the other listed options.

However, your filesystem choice won't be the biggest single limiting factor when it comes to system speed. If you're a forward-looking person, then much as I hate to say it (again!), much as I like ReiserFS, you're probably better off not using it, and going with ext3 (or even ext4 once it's worth using).

vagif · 2007-12-28 02:39:12

nightmorph wrote:

Look in /etc/mke2fs.conf.

Thank you ! It is exactly as you said. dir_index is enabled by default.
Archlinux rocks!

Gullible Jones · 2007-12-28 02:43:06

If you value your data, do not use JFS. It's the best overall performer, but the Linux implementation has a nasty issue where written files get deleted en masse when they shouldn't. Wait until this bug is resolved before using JFS to store anything important.

As for the other stuff... Here's what I've seen.

- ext3 actually performs quite well overall. However, directories take up a lot of space on it, and certain operations may cause a bit of grinding.

I used to use it with dir_index, but later found that didn't make much difference. I also recall reading somewhere that dir_index can increase application launch times, but never confirmed it. At any rate, it's a good choice.

- ReiserFS is very fast for anything involving lots of small files, and unimpressive otherwise. Mount time issues have been resolved, and applications seem to launch faster with it than they used to, though. On the other hand, it can fragment over time (especially if you don't use notail IIRC), and cannot be properly defragged.

Currently I'm using ReiserFS with notail (and of course noatime). It's stayed fairly fast, and seems quite stable.

- With XFS, loading applications and anything that involves (relatively) large files is very fast. However, performance will be *abominable* on any task involving large numbers of very small files (read: pacman).

XFS is sort of ReiserFS' opposite number. It's a good filesystem, if you don't mind the aggressive caching, but if you don't use pacman-cage with it you'll be in for a tough time. It also has more of a tendency to fragment than other FSs, but there's a very fast defragger... so no problem there.

PDExperiment626 · 2007-12-28 09:17:32

Gullible Jones wrote:

If you value your data, do not use JFS. It's the best overall performer, but the Linux implementation has a nasty issue where written files get deleted en masse when they shouldn't. Wait until this bug is resolved before using JFS to store anything important.

I have been using JFS for quite some time and have never had an issue with data loss that was undoubtedly due to JFS. As I've said in other threads, blaming a file system for data loss without posting official bug reports or making efforts to determine whether or not it ACTUALLY is a file system problem serves no purpose whatsoever. I still have yet to see anything about JFS that conclusively shows it has a data loss issue; and I am not aware of any bug report filed with the IBM devs regarding this issue. Given that a core group of IBM devs still maintain the linux JFS port, I'd imagine a true bug pertaining to data lose would be on a high priority .

ibendiben wrote:

JFS - IBM's Journaling FS. JFS is very fast and uses the least CPU processing power of any filesystem. Very fast at mounting. It has been reported on the JFS mailing-list that it could suffer from fragmentation problems.

JFS file system will indeed fragment and degrade performance. However, there is a way to defragment a JFS file system ever so often to keep the performance at its highest potential. This issue is discussed in the Arch wiki article on JFS.

As for support on JFS, it is still actively maintained by the IBM devs (as far as I know). Really, unless Linus decides to massively alter the VM subsystem in the kernel, JFS probably won't be going through any major changes in regards to linux.

My personal recommendation for a file system is for you to try all them and see what works for you; it's worth the time shopping around for a file system that fits your needs the best. If you are interested in JFS, there is an Arch wiki article on it, if you wish to learn more.

Last edited by PDExperiment626 (2007-12-28 09:25:12)

test1000 · 2007-12-28 13:12:57

My personal recommendation for a file system is for you to try all them and see what works for you; it's worth the time shopping around for a file system that fits your needs the best. If you are interested in JFS, there is an Arch wiki article on it, if you wish to learn more.

No! Just choose ext3; the only file system that can officially call itself rock-stable (the kernel devs seems to think so.. and me too..)

Imagine this scenario, your graphics driver crash and you have to hard-restart, when you reboot, linux doesn't boot. So you boot your rescue cd and oops, the rescue cd doesn't support your FS/and/or version! ext3 to the rescue! yes, 'been my experience..

Unless you have a really slow computer i don't see what the point of another FS would be, what specifically does another FS help you to do which you couldn't do with ext3 guys?

Last edited by test1000 (2007-12-28 13:16:05)

Ashren · 2007-12-28 13:46:29

Slightly OT. The gentoo guys seem to be very keen on ReiserFS 4, my question is why?

lucke · 2007-12-28 14:06:54

As I see it, some Gentooers really like to twiddle and make the most of their systems; and Gentoo's structure, quite like Arch's, enables them to do so - hence interest in Reiser4, and that's why most of patchsets originate in Gentoo community. Apparently, interest in Reiser4 is slowly fading away even amongst Gentooers. On a side note, if I'm not mistaken, freshly formated Reiser4 really speeds up portage.

attila · 2007-12-28 18:20:05

Gullible Jones wrote:

If you value your data, do not use JFS. It's the best overall performer, but the Linux implementation has a nasty issue where written files get deleted en masse when they shouldn't. Wait until this bug is resolved before using JFS to store anything important.

It would be nice to say more and a link to this information would be nice too. Until then i enjoy it running on three pc's.

cactus · 2007-12-28 19:00:32

vagif, if you don't consider yourself an advanced linux user, then I probably wouldn't recommend JFS or XFS.

I would say stick with ext3 until such time as you discover a need to change to something else.
ext3 works pretty well, is reasonably fast, well supported by just about any livecd, and has good documentation on usage.

Mr Green · 2007-12-28 19:52:23

/me agrees with Cactus :-)

vagif · 2007-12-28 21:00:49

I'm not afraid of using JFS. I think it is stable enough for me.
But while my previous questions are answered, new questions keep coming up.
I read JFS page on Arch wiki. It says that JFS could get fragmented over the time, and the only defragmentation technique is a script that copies data to another drive, formats original drive, and copies everything back.
That' is scary, takes long time, and i do not think i will have another big enough drive on my laptop just for defragmentation purposes.

How JFS users cope with this problem ?
Is fragmentation an issue or can I ignore it ?
Is fragmentation an issue on ext3 ? and if yes, how do you defragment ext3 ?

lucke · 2007-12-28 21:34:33

From my tests, JFS, thanks at least partially to extents, fragments a lot less than ext3 and even ext4 with extents, when copying files into a fresh filesystem - thus overall I don't think it fragments any worse than ext3 in a long run, if not better. Fragmentation of filesystems isn't that easy to evaluate and its effects aren't easy to benchmark, because there isn't an easy way to get a nicely fragmented filesystem, it just takes time.

Only XFS from Linux filesystems has a tool for online defragmentation - the only way to defragment other FSes is by copying partition's contents somewhere, reformatting and copying back.

Filesystems is really a funny field - there's almost as many opinions as people.

Last edited by lucke (2007-12-28 21:35:35)

byte · 2007-12-28 22:51:18

Regarding the fragmentation issue, this is probably the single most useful advice, even filesystem-independent: Don't let it fill up too much.

attila · 2007-12-29 09:38:35

@vagif I agree to byte that fragmentation is filesystem-independent and so for me it is not the most important point.

Only for the stats: I run on my 3 pc's (1 opensuse server and 2 arch linux) jfs with the relatime mount option and the deadline scheduler. Until now i never lost any file or contents. And yes, instead that linux runs stable, there were moments where i have to press the reset button.:)

delphiki · 2007-12-29 14:06:01

@attila: One quick question, but do you use JFS for your / partition as well? or do you use a combination of different file systems?

PDExperiment626 · 2007-12-29 14:16:00

vagif wrote:

How JFS users cope with this problem ?
Is fragmentation an issue or can I ignore it ?
Is fragmentation an issue on ext3 ? and if yes, how do you defragment ext3 ?

The reality is, you probably won't notice a the speed hit from JFS fragmentation on a desktop system. The reason why there isn't any built-in defragmentation in the JFS code itself is because the JFS devs believe it would incur a too large performance penalty for a marginal gain in disk access time due to lower fragmentation.

In reality, I have not noticed a significant slow down due to JFS fragmentation; and I have run the file system for over a year without defragmenting. There is little information put out about the nature of fragmentation for ANY file system (look how long it took for MS to own up to the fact that NTFS does indeed get fragmented). Don't assume that just because fragmentation isn't mentioned with other file systems that it isn't a real issue. The fact is, with most modern file systems, most people don't notice the performance hit with a highly fragrmented partition.

As for using ext3 because it's the only one supported by a live CD; this is ridiculous. JFS is built as a module on almost ANY default kernel build for any distro; and thus will be recognized by almost any liveCD boot. If you boot an Arch CD, your JFS partitions will be recognized; and all the JFS utilities will be available to you.

I still stick by what I said before, try out different file systems and make up your own mind; you won't ever get a straight answer by listening to forum posts .

As for stability, obviously the kernel devs thought JFS was stable enough to officially merge into the kernel sources some time ago.

PS - If anyone knows of a proper JFS defragmentation utility please let me know and I'll write it into the wiki (I authored the current version).

Last edited by PDExperiment626 (2007-12-29 14:23:18)

lucke · 2007-12-29 14:54:36

Fragmentation can be an issue. To say the least, I love XFS for its online defragmentation, delayed allocation and extents, xfs_bmap and RESVSP (instant space allocation). To demonstrate: after a bit of downloading torrent data on a fresh XFS partition on my server, I realized that copying the data to my desktop is excruciatingly slow. Running xfs_db showed 99% fragmentation. After defragmenting, everything flew like it should (max from 100Mbs link, instead of 1MB/s). Afterwards I hacked rtorrent to use RESVSP - difference of performance between fully allocated and non-allocated files is striking. Downloading unallocated torrent data is obviously quite an extreme example of fragmentation, but it clearly shows its impact on performance.

Some links:
Effects of fragmentation on ext3 and reiser4
Interesting observations on filesystems, with emphasis on JFS

Gullible Jones · 2007-12-29 14:58:21

Re JFS data loss: bug reports have been filed. See here and here.

PDExperiment626 · 2007-12-29 15:57:32

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)

Arch Linux

#1 2007-12-27 22:53:37

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

#2 2007-12-27 23:19:04

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#3 2007-12-27 23:31:28

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#4 2007-12-27 23:34:15

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#5 2007-12-27 23:46:13

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#6 2007-12-28 00:15:18

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#7 2007-12-28 02:05:18

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#8 2007-12-28 02:39:12

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#9 2007-12-28 02:43:06

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#10 2007-12-28 09:17:32

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#11 2007-12-28 13:12:57

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#12 2007-12-28 13:46:29

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#13 2007-12-28 14:06:54

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#14 2007-12-28 18:20:05

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#15 2007-12-28 19:00:32

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#16 2007-12-28 19:52:23

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#17 2007-12-28 21:00:49

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#18 2007-12-28 21:34:33

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#19 2007-12-28 22:51:18

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#20 2007-12-29 09:38:35

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#21 2007-12-29 14:06:01

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#22 2007-12-29 14:16:00

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#23 2007-12-29 14:54:36

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#24 2007-12-29 14:58:21

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

#25 2007-12-29 15:57:32

Re: ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

Board footer