Tell me about ZFS. Is it actually viable for everyday usage?

>>56194309
Yes

>>56194309
Define "everyday usage". What are you doing and on what kind of computer? What features of ZFS attract you?

>>56194309
Yes, but it uses a lot of memory. btrfs is better in some ways, worse in others. HAMMER2's pretty good, too.

Apple's new APFS is a huge disappointment by comparison.

>>56194541
ZFS gets by fine on modest amounts of RAM. It'll use as much as you can give it for caching, but every filesystem on every OS does that.

Unless you turn on deduplication. That needs something like 5-6GB of RAM per terabyte of storage or else it's dog fucking slow. Don't turn on dedup.

>btrfs
RAID1 works fine these days but RAID6 is fucked. Which is a damn shame because it'd be really convenient for the home data-hoarder. There's still some corner cases where btrfs really gets its pantsu in a knot. Don't put VM images on it.

>HAMMER2
I've never used it, so I don't have an opinion

>>56194361
>Define "everyday usage"
Move my everyday shitposting machine from ext4 to zfs
>What are you doing and what kind of computer?
automating backups and having an easily syncable shared partition between the machines (afaik it looks like it'll be one machine writing and pushing it to the other which is fine for my usecase). it'll be a laptop, server and another external solution for starters, maybe add another machine to the loop later
>What features of ZFS attract you?
snapshots, data integrity checking, nice looking raid implementation

>>56194738
well since you mentioned ext4 I'll assume you're using Linux and want to keep doing so.

You can boot from ZFS on Linux, but it's tricky, because that CDDL shit means it can't be in the kernel and has to be a loadable module. (usually this means it gets compiled and installed with DKMS)

Anyway if you want the data integrity features you need two drives minimum. Three would be better, if you aren't planning on booting from it. That's how scrubbing works in both btrfs and ZFS, because both of them are a RAID layer, volume manager, and filesystem all rolled into one, the filesystem, when it sees a bad checksum, can ask the RAID layer "Hey, this is bad. Can you get it from another disk for me?"

The biggest problem a home user will have with ZFS is that vdevs are immutable. (A ZFS pool is essentially a RAID0 of all the vdevs in it) Once you add a vdev, you cannot remove it or change its raid level, and each vdev has to bring its own redundancy. Lose one vdev and the whole pool dies. ZFS kinda assumes it'll be used in a datacenter where buying drives by the dozen is no big deal. The easiest way to make it affordable and expandable on a small scale is to use mirrors (RAID1) and avoid RAIDZ (RAID5/6/7). That lets you add or replace drives two at a time to increase capacity, but it also means that your capacity is only going to be 50% of your raw storage. The upside is that mirrors are faster than RAIDZ. I have 6.5TB on my array (in five mirror vdevs) and it scrubs in under 12 hours.

I wouldn't put it on your laptop if I were you, keep it on a desktop machine somewhere. Let bulk data and backups live there, and sync things to your laptop as needed. If you want snapshots on your laptop, that's probably a good place for btrfs. It's in the kernel and Linux is happy to boot from it out of the box.