Something like the following in /etc/fstab might help to speed up read-write-delete in directories with many subdirectories and/or many files - especially small files:

I once read that a filesystem should not be blamed for loss of data. It is the job of a filesystem and its associated utilities to make sure it comes back online in a consistent state after something like a power cut, not to restore data. That is what backups are for, and thus, this is not a problem that needs to be "fixed" in the filesystem. All I can tell you is that XFS has not let me down once, and I've had several unexpected power cuts. But XFS and JFS were designed as server filesystems from the outset, so perhaps that will guide your thinking when it comes to using one or the other on a laptop.

For a completely anecdotal comparison, my server uses XFS and I did not lose data despite a partial hardware failure of the hard drive (which had to be replaced, but I was able to copy the data off of it). Meanwhile, a regular power-out recently corrupted my /usr partition on my desktop's ext4 filesystem. Both are good filesystems and have different strengths, but I'm not sure there is any good data about filesystem failure probability, since it is hard to measure (and there is anecdotal evidence favouring every filesystem from someone). I have no plans to stray from ext4 on my desktop, nor to stray from XFS on my server (with the possible exception of btrfs if it becomes a little more mature).

I have all my CD's ripped to a directory in a /Artist/album layout. Doing a ls -d */* to get a list of all the albums across all artists was taking around 4 seconds on JFS. Doing the same operation on ext4 took approx half a second. I also noticed that things such as git operations were very much slower on jfs too. Once things were in the filesystem cache things were more equal but jfs was still slower.

I've always known that jfs file creation/deletion was slower because of the dynamic inode structure it uses, but I hadn't appreciated that it also affects directory traversal/metadata reads quite so badly. Anyway, I've switched back to ext4 now, though I was very tempted to try out xfs.


Just had a pretty nasty electricity brown-out tonight. Everything looks intact, but in these situations I think it's more a case of luck than anything else. When power fades in and out like that it's anyone's guess what will happen at the disk heads.

Oh boy, yesterday while copying almost 200GB worth of music from my previous machine to my new (xfs) machine we were experiencing a brownout where the tv wouldn't even stay on followed by a 5 hour outage. The culprit was a transformer that failed which in turn burnt down one of the overhead lines causing another transformer to fail. I didn't realize the electrical issue until after the copy had completed (4.5 hours!). Right now I'm md5'ing both directories. On the bright side it's my first test of xfs and the power seems steady for the first time in almost two years since the new transformers were installed!

Deleting files on JFS is instantaneous.
Here's my benchmark of more recent filesystems:
http://www.linuxquestions.org/questi...k-data-900888/

Certain options like data=writeback on ext4 will make data loss more likely. Any filesystem that caches data to RAM for extended periods is more susceptible.

Quite an interesting presentation on recent XFS improvements that are now available in recent kernels:

http://www.youtube.com/watch?v=FegjLbCnoBw

1 members found this post helpful.

As big a fan of XFS as I'm, I have to say that deleting files is slow when filesystem is more than 90% full.
However, my "home" filesystem is over 5 years old, and I've had at least 20 power outages at this place. But everything is still fine. No file corruption at all.

@H_TeXMeX_H: What kernel were you running in your benchmarks? The stock 2.6.37.6 from 13.37? If so the XFS improvements that fix the major performance bottlenecks are not found until 2.6.39 and up. Phoronix found that in some benchmarks like PostMark v1.5.1 Disk Transaction Performance, XFS had a 6.4x performance improvement in modern kernels. I'd be very interested to see how XFS performs in Slackware 14.0. I suspect it will perform a lot better.

Interesting video. I have let my curiosity get the better of me and reinstalled slackware 14 on this new laptop of mine.

XFS on a 120 gig root partition on an ssd. Mounted with "defaults,noatime,discard". Everything seems to be working pretty well

Yeah, it is the stock kernel. I will test it in slackware 14.0 as well.

Other readers should bear in mind that LILO must be installed to the MBR if they format their root partition with XFS. LILO will not boot if it is installed to a XFS-formatted root partition. (They can of course create a small ext3 /boot partition and install LILO there instead.)

More here.

Using raiser where system is isolated, and ext3 if MS Windows is neighbour(did not meat any normal developer who wishes to port raiserfs driver to windows, only dumbs).

Sorry for reviving this thread, i've only just returned from a holiday.

This statement is so true. "Consistent", btw, means: not only does fsck succeed, but the file content doesn't change silently. Which in turn is the reason why mount flags like data=writeback and nobarrier for ext4 are ludicrous: consistent data is not guaranteed. Even worse: depending on writeback parameters, an inconcistent state is present on disk over prolonged periods of time, just waiting for an accident to happen.

As konsolebox pointed out earlier: if you know what you're doing and if you have measures in place to deal with the unspeakable, go for it. Everybody else, stay away.