Best FS for Slackware
 

Hi Forum,

I have seen various threads on this, googled for the Truth, but so far I have never found a decisive answer...

What FS should I use for a reliable and fast ( like in I/O ops )deployement of an OS...?

Ext2 Ext3 Ext4 XFS JFS...?

BRGDS

Alex

I think it depends on the application. One fs may be better for db workloads and others for desktop purposes. I've been running jfs for a loooonnng time now on my server (has very low I/O load) and my desktop. Seems to work pretty good.

SUN's ZFS has a very good reputation. But as you probably already know you won't find it in Linux anytime soon despite the ZFS for linux project...

Would you like to try it, go for Open Solaris or for very recently released FreeBSD 8.0

Beside that I forecast a very loooooooong thread following such a question with a _lot_of_not_so_convincing_answers_ ;)

From Chaos of Darkness let there emerge the Light of Truth... :-)

Alex

Using Ext4 here for a long time. It's fast and stable for me. No issues.

Hi,

I think a general response would be to use 'ext2/3'. But the choice of filesystem should be selected to support the needs of the system and how that system will be used.

If you keep personal opinions out of the scope then 'ext2/3' and now one should consider 'ext4' with certain installs. There's been so many benchmarks for filesystem comparison that I just rely on my on uses or needs.

:hattip:

I recommend XFS or JFS. I've never had any problems with them. I also recommend AGAINST ext4, it is dangerous by default in order to improve speed. Also check the XFS options, because some options can be dangerous. By dangerous I mean that in the case of an unexpected loss of power or crash, data may be lost.

I haven't got round to checking out all the different filesystems, so I've just used ext3 in the past, and ext4 on 13.

Ext4 is dangerous? Can you explain or at least provide a link?

I like reiser fs for the way it packs data on the drive and it is fast

ext4 is a good multipurpose choice, the other option IMHO is JFS.
Advantage of ext4: As the default FS of current Linux, it can support everything that the Linux kernel can do with an FS, such as increase or shrink and so on. As far as I can tell, it is faster than ext3, but as one poster has said, it's journaling mechanism is not the most robust instance of its kind (at least, in its default configuration; this means there's a certain risk that you lose data when your machine or hard disk crashes). But then, no other modern FS is supported better by standard Linux tools.
Advantage of JFS: Fast and lean (low footprint, fast and robust journaling).

XFS is also excellent, especially for multimedia servers. It is the best FS for the handling of large files (bigger than 100 MB, such as films and videos).

ReiserFS used to be my recommendation, but the future is uncertain...

This is what I can tell from experience. Currently I use ext4 for just about everything, and NTFS on an external USB device to share data with Windows users. No issues, so far (machine was set up about four months ago).

gargamel

Ext2 and ext3 have tried and test reputations and both served me well, though I have had cause to appreciate ext3's journalling a couple of times over the last few years and so said bye to ext2 after slackware 11.

Ext4 has been noticeably faster than ext3 and I've not had any data loss issues with it on my daily use work laptop since installing slackware 13 a few months back. Only prob I had with ext4 is that distros with grub 1.x couldn't boot if the kernel was in an ext4 fs - easy to fix by installing grub2 or lilo from slackware 13.

Is there anything out there to let you access ext4 partitions from windows? I remember that was a problem for me in the early days of ext3.

Another vote for ext4. I won't debate over its merits or problems.

Recently switched some of our JFS drives over to ext4, and am in the process of switching the rest from JFS to ext4.

Had a few drives mysteriously get corrupt super blocks while using JFS. These were drives that routinely see 130MB/s-150MB/s sustained read/write for periods of time (transferring 15-20gig's of data at a time). Strange that they are all 1TB Samsung F1 drives - yet our 500gig Samsung F1 drives are fine with JFS, though they don't see as much traffic as the 1TBs do. Formating the 1TBs to ext4, still going strong without a hiccup.

I'm sure a benchmark would prove one file system faster than the other. Can't personally say which one it is, as there is not enough of a difference for us to notice.

I wanted to trouble shoot the constant corrupt super block issue, but the JFS mailing list is dead, little to no development, jfsutils is missing many features that are in other file systems like ext3/4 and xfs. No way to repair the super block without having a dd'd backup, and debugfs is a PITA. The mailing list does have other people with the same corrupt super block issues, but they either have little or no replys.

I'm once bitten twice shy by XFS. 8 or 9 years ago XFS taught me how important backups are. They say there's two types of people - those that back up regularly and those who will. Today, XFS is far and away different from what it once was, the issues it had then are long gone. But I still grumble every time someone mentions XFS ;)

Every file system on any controller that does not employ a battery backup with a RAM cache can cause data loss in the case of an unexpected loss of power or crash. The beta-staging-prealpha ext4 had a longer cache cycle, so if you had a document opened at the time of the crash it did not sync to the drive. So instead of a corruptly written block with most likely unrecoverable data, you wouldn't have had anything written with ext4. Before this version of the prestaging module, the open sync time was even longer. This has long been fixed. With the current versions of ext4, your corrupt data will be written to the hard drive just like every other file system so you can fail at an attempt to recover it.

See:
http://www.linux-magazine.com/Online...-Ext3-and-Ext4

and much more was posted on the topic a while ago here on LQ, just search for it. I don't think anything was done about it except to maybe warn users.

Either way, if you want a thoroughly tested fs, choose ext3. If you want performance and also reasonably good reliability (but not quite as extensively tested) choose XFS or JFS.

That was changed in the next kernel release, which was 2.6.30 (Slackware 13.0 is shipping 2.6.29.6 as far as I know).

http://kernelnewbies.org/Linux_2_6_3...730418cdd6630d

But ... but ... wait a minute, that means they changed ext3 to default writeback mode, so ...

http://www.linux-magazine.com/Online...-Ext3-and-Ext4

Doesn't that mean things went from bad to worse and you should change it back to the old ordered mode ?

I won't pretend to be a file system expert and won't try. :)

On my systems I use ext3. Simple and straightforward. Yet for my video storage partition on my HTPC I use xfs. The xfs system is supposed to provide better support for large files. That is my experience too. For example, deleting a TV recording --- files that can be many GB in size, requires only a second or two with XFS yet requires many seconds with ext3.

Sorry, but I think I provided a source of confusing and contradictory information. I don't think ext3 defaults to writeback now, but I'll have to verify it later. I've been reading blog posts and news in the last few minutes and this is the best explanation of the issue with ext4 and how it was solved in 2.6.30. From Teodore Tso's blog:

http://thunk.org/tytso/blog/2009/03/...-file-problem/

Edit: an update. Yes, writeback is the default now unless you mark the option "Default to 'data=ordered' in ext3" in the kernel menuconfig, in the "File systems" section.

If you don't mind performance, go for reliability and choose Ext3.
If you want to optimize your system, use something like this:
/tmp - reiserfs
/var/tmp - reiserfs /it works better with small files/
But if you ask me, if you have enough RAM it's best to use a small portion of the ram for tmp's.
/ - xfs
/home - ext3 /for reliability reasons/

Or use ext4 for all except the tmp's.

I've noticed that some software is not compatible with ext4 nor the 256-byte inode size that is used with ext3 on some newer distros. I always format my filesystems with ext3 and 128-byte inodes for that reason.

The following is software that I know does not work with ext4 nor 256-byte inodes.

• Paragon Hard Disk Backup 9
• Paragon Partition Manager 9
• ext2ifs (ext2 Installable Filesystem for Windows)
• Some versions of grub

Wasn't the ext4 that shipped with Slackware 13.0 already patched for the sync problem?

I have been burned by ext3 enough times that I shy away from it. Tried Reiser and my friends sblock corrupted in less than a week. Not being a doomsayer, but my neighborhood has really bad power. It has killed several UPS systems I have bought to try and mitigate this headache.

So far, I have had the best luck with JFS and XFS. When my power gets cut they just keep on ticking. I don't pretend to have an answer why, but I'm sold on them. I just bought a Gateway LT2030u netbook this week and installed Slack13 with XFS and it is running great.

I can't speak to what applications will not work with Ext4 nor for what reason(s), but I just wanted to say I have been using Ext4 shipped with Slack13-64 for many months now without a single hitch. Power outages don't bother it, and I have not a single AWOL file in Lost+Found since installation.

Bad shutdowns either reboot cleanly, or I have had a very rare fsck that lasted literally a few seconds and the boot continued without issue.

I had odd occurrence last night on my ext4 partition (slack64-current).

Was using mythtv and the file location I gave it was the ext4 but it got full. Eventually I had to killall mythfrontend and mythbackend even though the terminal kept reporting insufficient space errors.

At the time, I was also playing the einstein game. This morning the einstein hidden user directory was either deleted or the scores file was lost. That loss is not important of course but I don't know what else might be lost.

I was using ext3 (slack13) on a different partition and remember these long delays when trying to delete something. I never understood the delay but now when reading about the ext4/ext3 writeback schemes it might make sense. Here and here.

The current ext4 system seems to still be working so if other files are lost I haven't noticed yet.

The radeon changes coming in 2.6.32 will make it a fairly useful version and the ext4 issue is supposedly resolved in 2.6.30.

The answer is very simple for me.

For a reasonably-sized / partition: Ext4
For a large storage area (~500G+): XFS

I use a custom kernel (2.6.31 as of now) and I use ext3 on my /home partition and ext4 on the rest (ext3 mounted with data=ordered mode, the safe choice). I consider the data in /home the most precious, so I play safe there. I think in a typical desktop scenario the disk performance usually matters most during application start-ups (when a lot of read is made from /usr), so I sacrifice a little bit of safety for speed by using ext4 outside /home.

Btw, there was work in progress for a compromise mode between data=ordered and data=writeback. Does anyone know if it made it into the kernel yet?

How did you get these "metrics"? Personal experience? Benchmarks?
Just curious, because I tried ext4 on an external 1TB USB device. It works, but it is not really fast... Maybe I should switch to JFS or XFS for this device.

gargamel

I had lots of trouble with nearly all filesystems, especially XFS (have you ever tried to store a rsnapshot repository on a XFS volume?), data corruptions and losses with ext2/3 after power failures, etc.

But I never ever had any issues with JFS, which I now use as an all-time all-purpose filesystem from netbook to many servers since a few years.

JFS is clean and well designed, rock-solid, fast, and it uses the least cpu power in nearly all benchmarks I saw. Plus: if you ever experience some inconsistencies you have excellent tools at your hand (wish one could say this about XFS).

I have to say, I had JFS on my external USB 1TB device, but I had problems with the partition table after LUKS encrypting it. But I don't know, if the problems were caused by the file system or by something else...

Does anyone have experience with JFS and LUKS encryption on external USB devices? Does it work? It should, but see above...

gargamel

read up and decide for yourself

http://www.debian-administration.org/articles/388

See http://kernel.org/faq/#howdoesitwork

If what's good for Linus is good for Alex, then try XFS ;)

Caveat : but you can't shrink it directly, see http://xfs.org/index.php/XFS_FAQ and http://gparted.sourceforge.net/features.php

[EDIT] And you can't install LILO on a (XFS) root partition, only on the MBR. That'd be a problem for me as I want to preserve my Windows' boot loader (yes, I do launch it every now and then) on my Lenovo Thinkpad T61 (thus /dev/sda4 being my root Linux partition I have "boot = /dev/sda4" in lilo.conf and I made /dev/sda4 bootable).

Very old link though, does anyone have any recent benchmarks? I found one of osnews but that was of 2007. :\

One note:

If you choose JFS make sure to read:
http://wiki.archlinux.org/index.php/JFS_Filesystem

it mentions several important things.

Yes, I do it a lot, have several LUKS encrypted JFS formatted USB disks. There is nothing special to do or to tell about. Just have a look at ftp://ftp.slackware.com/pub/slackwar...ADME_CRYPT.TXT

Thanks, I'll try it out another time, then.

gargamel

The "problem" you quoted does not exist. The delay time can be tuned. It's not specific to either filesystem. The most possible reason why you tune the write delay is switching between battery and mains (laptop users).

BTW, in recent kernels, the default mount options of ext3 also changed to more dangerous values to improve performance.

Hi,

Please expand on your solution other than to make an arbitrary or just plain ambiguous statement. I've yet to experience problems with ext3 and I am curious where your getting the information.

:hattip:

There was a long thread (titled like "slow application startup" or something) where this issue about ext3 came up. There was a kernel bug known as the Linux I/O wait bug, there were long discussions on the kernel bugzilla page. In the end it was closed as unresolved, since there appeared to be multiple factors causing high wait times. Some of these were filesystem-independent, likely to be related to the scheduler, but there was disagreement over whether it was a bug or just the expected behaviour under load. I don't know if they did any changes to the scheduler code about this. If what you're referring to above is this part of the problem, afaik you can't tune the delay time (unless you tinker with the kernel maybe?).

However there were also cases that were tracked down to the ext3 code (more specifically, to the way data=ordered mode behaves). There were so many complaints that they ended up switching the default mount option to data=writeback in ext3 and ext4. This is the unsafe choice, even Torvalds was openly against the idea. There were reported cases of data loss, too. I think they did little improvements to reduce the risk. Some Ext4 developers even said "it's not a bug, it's a feature" and blamed on poorly written application codes for not doing necessary checks and assuming certain behaviour. Anyway, writeback is still considered the unsafe default. As I said above they were working on an intermediate solution but I haven't followed up on that.

I've been happy with JFS. I use ext2 for my boot partition; ext3 or JFS for the remainder partitions. With Slackware I use JFS; with debian and CentOS I use ext3.

I had two crashes running Ubuntu on ext4 partitions. I was not able to do any recovery after the crashes. One of the machine would not even boot.

See http://www.h-online.com/open/news/it...t4-740467.html
and https://bugs.edge.launchpad.net/ubun...81/comments/45
about the 7th paragraph down where it talks about delayed allocation.

-JJ

I'm using ext4 with 'noatime,barrier=0,data=writeback,nobh,commit=100'. It's being solid until now, but my backups are synced every night ;]

The other machine is working for years with Reiser and abused really hard without problems. I'm just waiting my vacation to format one old spare rig and install Slack with JFS and satisfy an old desire to try this fs.