

Xfs is still faster but ext4 is catching up on large file creation - didip
http://tytso.livejournal.com/64071.html

======
gaius
This is astonishing. XFS is from 1994...

~~~
nodata
XFS had a different use case. Pull the plug on XFS and you have problems.

~~~
mansr
That is a misunderstanding. All reasonably performing filesystems lose data if
you pull the plug. The difference with XFS is that it buffers writes more
aggressively than e.g. ext3, so the amount of lost data may be greater.
Properly written apps fsync() any precious data anyway, so this is not an
issue.

The notion that XFS is unreliable probably stems from the way such lost
buffered data has historically been handled. Because XFS allocates the space
ahead of actually writing the data, files with unwritten data at a reset could
have visible zero-filled blocks after recovery whereas ext3 would simply
truncate them. In both cases the data was lost.

Since a while back, unwritten extents like these are detected and trimmed
back, so now XFS behaves more like most other filesystems. There are still
more buffered writes floating about, of course, so the same precautions are
still required.

~~~
rbranson
So what you're basically saying is with a modern kernel, if you pull the plug
on XFS or EXT3/EXT4, to the end user, they are equivalent?

~~~
mansr
All of them lose data. XFS risks losing more data than ext3. I don't know how
ext4 behaves.

A more important aspect is how well the filesystem recovers from having the
plug pulled, and here they all do well. Once written to disk, data is stable
in all of the mentioned filesystems. This is in contrast to non-journalling
ones where an unclean shutdown can render the on-disk data inconsistent and
difficult to recover.

------
didip
More comparisons and benchmarks are available here:
<http://free.linux.hp.com/~enw/ext4/2.6.36-rc6/>

------
adamzochowski
I wonder when will ext4 support file systems above 16tb (limit from 4k
clusters with 32bit addressing).

