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.