Quoting Hendrik Boom (hendrik@???):
[RAID1:]
> 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.
Which is properly called rendundancy, in contrast to backup. (You might
continue to choose to differ, in which case we agree to disagree,
please.)
> That's why I also keep separate off-line backups.
Which is properly called backup. ;->
> TRIM because SSDs?
That's what TRIM (capitalised not as an acronym but rather because it's
a style convention for the names of ATA commands) applies to. Your
question lacks context and clarity as stated, so I don't know whether
you're saying you are fundamentally unfamiliar with the issue. You
might be saying that. If you are:
https://en.wikipedia.org/wiki/Trim_(computing)
https://wiki.debian.org/SSDOptimization
https://wiki.archlinux.org/index.php/Solid_State_Drives
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4519
Also covers block alignment and other issues raised by SSD.
> I like the checksum protection of ZFS and btrfs. If I could get it
> with ext4 I'd be happy.
Don't hold you breath waiting. ;->
> 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.
I'm pretty sure it totally rules out ZFS. The usual RAM suggestions
start at 8GB, and go upwards from there. It's possible to have a
crawling^W running system with less (like, as low as 1GB), but you
wouldn't like it.
[btrfs:]
> Scarily beta, yes. I'd consider it if it ever stops being scarily
> beta.
Don't hold you breath waiting.