Quoting Hendrik Boom (hendrik@???):

> As I understand it, there are a few new file systems somewhat
> available on Linux -- ZFS, XFS, and Btrfs.
>
> But soe are still under development, ZFS is pparently under a
> prolematic license, and I don't know about XFS.
>
> I've onece heard about one of the new systems that one shouldn't
> bother using it unless one has at least 8 gigabytes of RAM.
>
> Now, just how mature are these, how easily managed, how reliable.
>
> I'll be populating a new device with a (I hope) high-reliablity file
> system soon. It doesn't have a lot of RAM, but the RAM does have
> parity checking.
>
> Long-term data preservation is more important than speed.
>
> Currently on another system I'm using ext4 over LLVM over software
> RAID-1. I know RAID isn't a reliable backup system; I make separate
> off-line backups.

Specifically, RAID isn't backup at all. It's redundancy (except for
varieties like RAID0 that aren't even that). See: 'Backup Fallacies /
Pitfalls' on http://linuxmafia.com/kb/Admin/

> What should I be considering for the new system? The same?

You've just asked one of the more inherently debatable questions in all
of Linux system administration.

I can only recommend that you study what the strengths and weaknesses,
advantages and disadvantages, are of the various options at hand, and
then design a system that implements your choices.

For my own home server rebuild, I'm going with ext4, with all
filesystems RAID1-mirrored across a pair of SSDs, and a weekly cron job
applying TRIM. No swap (because SSDs).

XFS is mainline kernel code under GPLv2. It is particularly good for
filesystems with mny very large files, e.g., audio/video. It isn't
quite as fast and massively QAed as ext3/ext4 (though the performance
difference is smaller than it used to be) . XFS is _not_ new. SGI
ported it to Linux in 2000. Like ext3/ext4 and unlike ZFS/btrfs, XFS
lacks checksum protection against silent data corruption.

ZFS is indeed under a GPLv2-incompatible licence[1] (CDDL). It's the one
that requires larger RAM overhead, but has a number of very compelling
features[2] especially for extremely large (multi-terabyte) filesystems.
The driver code is (obviously) not part of the mainline kernel, but
rather runnable either as a large external patchset or as a FUSE
Filesystem in Userspace subsystem. The latter has a performance
penalty. The former... entails running an out-of-tree kernel.

btrfs is still scarily beta after rather a lot of years of development.
Its prospects have dimmed further now that Red Hat have dropped it from
their roadmap.


[1] Canonical, Ltd. have asserted their recent distribution of
binary-compiled ZFS module code for Ubuntu to be lawful. My
interpretation is that they know this is false, that it is clearly
copyright infringement, but have taken a calculated risk that kernel
stakeholders won't sue them, and that the Linux-using public won't
object overly to Canonical lying to them for PR advantage.

[2] Volume manager is integrated into the filesystmem. Snapshots and
replication built in. All storage kept vetted by checksumming and as
necessary corrected. Automated self-healing. Smarter data-striping
('ZRAID') than conventional RAID modes. Native data compression /
deduping (which, however, is RAM-hungry). And a lot more: It's pretty
impressive.