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