[Nottingham] Filesystems: ReiserFS3.6 vs ext4 vs XFS (& ZFS?)

[Jim Moore]

short answer: if you're using static physical volumes (non-RAID, one
or more discrete partitions per volume, or massive partitions
[multiple tens of TB) over a RAID1, 5, 6 or 10), ext4 would seem like
the logical choice to me.
If you're planning on using dynamic volume resizing (ie using smaller,
hotswappable drives to hold archival data such as logs), or massive
volumes (RAID or not) for example for a hotel entertainment or
broadcast server, there's no real question: XFS.

As to ReiserFS, the only real advantage I find of that over ext4 over
multiple physical volumes is the ludicrous speed with which ReiserFS
seemed to be able to access directories with several hundred to
several tens of thousands of files. Not very useful if you're only
using it to run a home system, probably useful if a: you have a
reliable UPS and b: you have several million images/photos/clipart you
need a dev team or college campus to be able to access. Might also be
useful if you're running indexed bitmaps into a movie file (eg stop
motion CGI). Con for ReiserFS: after a power cut, it spends stupid
amounts of time rebuilding the journal....

cheers,

Jim

On 9/8/09, Martin <martin at ml1.co.uk> wrote:
> OK folks,
>
> Yet more filesystem questions/thoughts/comments...
>
> Should I be moving over to XFS rather than ext4?...
>
> Comparing which /filesystem/ to use, I note for:
>
>
>
> *ReiserFS3.6*
>
> http://en.wikipedia.org/wiki/Reiserfs
>
>
> Pros:
>
> Introduced in version 2.4.1 of the Linux kernel, it was the first
> journaling file system to be included in the standard kernel.
>
> Metadata-only journaling (also block journaling, since Linux 2.6.8).
>
> Tail packing, a scheme to reduce internal fragmentation.
>
> B+ tree design.
>
>
> Cons:
>
> Tail packing, however, can have a significant performance impact,
> positively or negatively depending on conditions.
>
> ReiserFS still uses the Big Kernel Lock (BKL) - a global kernel-wide
> lock - in some places, [so] it does not scale very well[3] for systems
> with multiple cores.
>
>
>
> *ext4*
>
> http://en.wikipedia.org/wiki/Ext4
> http://kernelnewbies.org/Ext4#head-25c0a1275a571f7332fa196d4437c38e79f39f63
>
>
> Pros:
>
> Removes 64-bit storage limits and adds other performance improvements to
> ext3.
>
> Extents introduced to replace the traditional block mapping scheme used
> by ext2/3 filesystems. An extent is a range of contiguous physical
> blocks, improving large file performance and reducing fragmentation.
>
> Pre-allocation of on-disk space for a file and multiblock allocator, for
> improved performance.
>
> Delayed block allocation until the data is going to be written to the
> disk, reducing fragmentation.
>
> Allocation alignment to an underlying RAID structure.
>
> Htree indexes.
>
> Journal checksumming.
>
> Timestamps measured in nanoseconds. Year 2038 problem defered for an
> additional 500 years.
>
>
> Cons:
>
> Its relatively new!
>
>
>
> *XFS*
>
> http://en.wikipedia.org/wiki/XFS
>
>
> Pros:
>
> XFS has a mature, stable and well-debugged codebase.
>
> Metadata-only journaling.
>
> Allocation groups, providing scalability and parallelism - multiple
> threads and processes can perform I/O operations on the same filesystem
> in parallel, that can span multiple physical devices.
>
> Allocation alignment to an underlying RAID structure.
>
> Extent based allocation
>
> B+ trees dual indexing scheme
>
> Delayed block allocation until the data is going to be written to the
> disk, reducing fragmentation.
>
>
> Cons:
>
> Any?
>
>
>
> Also, *ZFS* looks rather interesting:
> http://en.wikipedia.org/wiki/Zfs
>
> Shame about the licensing problems and the FUSE port being so recent
> (March 2009). Anyone played with it?
>
>
>
> *Write barriers*
>
> Write barriers look to be supported in all of ReiserFS, ext4, XFS,
> md-raid1. Does drbd now support write barriers?
>
> However, lvm2 appears NOT to support write barriers... Why?
>
>
>
> Comments?
>
> Should I be moving over to XFS rather than ext4?...
>
>
> Cheers,
> Martin
>
> --
> ----------------
> Martin Lomas
> martin at ml1.co.uk
> ----------------
>
> _______________________________________________
> Nottingham mailing list
> Nottingham at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/nottingham
>