On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote:
> Quoting Hendrik Boom ([email protected]):
>
> > 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/
It's not backup in any normally robust sense of the word. It does
provide a bit of backup against one potential threat -- minor
localized hard drive failures. That's why I also keep separate
off-line backups.
>
> > 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 know.
>
> 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).
TRIM 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.
I like the checksum protection of ZFS and btrfs. If I could get it
with ext4 I'd be happy.
> 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.
I'll have about half a gig of RAM. Does this rule out ZFS or just
make it moderately slower? I'm not going to be running millions of
transactions a day on my home server.
>
> 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.
Scarily beta, yes. I'd consider it if it ever stops being scarily
beta.
>
>
> [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.
> _______________________________________________
> Dng mailing list
> [email protected]
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
