Live data from Hacker News

Linus: Don't Use ZFS

realworldtech.com

371–380 of 571 posts

Re: Linus: Don't Use ZFS

#371
post #107
post #81

Earlier quoted context omitted.

Last time I used ZFS write performance was terrible compared to an ordinary RAID5. IIRC Writes in a raidz are always limited to a single disk’s performance. The only way to get better write speed is to combine multiple raidzs - which means you need a boatload if disks.

We had a bunch of Thumpers (SunFire X4200) with 48 disks at work, running ZFS on Solaris. It was dog slow and awful, tuning performance was complicated and took ages. One had to use just the right disks in just the right order in RaidZs with striping over them. Swap in a hotspare: things slow to a crawl (i.e. not even Gbit/s). After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much f…

"After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much faster, more robust."

Please let me know which company this is, so I can ensure that I never end up working there by accident. Much obliged in advance, thank you kindly.

Re: Linus: Don't Use ZFS

#372
post #166

Earlier quoted context omitted.

bcachefs should be heavily supported, it doesn't get nearly enough for what it supposes to do: https://www.patreon.com/bcachefs

Honestly just use ZFS. We've wasted enough effort over obscure licensing minutia.

I don't think something that is the subject of an ongoing multi-billion-dollar lawsuit can rightly be called "obscure licensing minutia." It is high-profile and its actual effects have proven pretty significant.

Re: Linus: Don't Use ZFS

#373
post #295

Earlier quoted context omitted.

Many of the advanced features aren't implemented yet though, like compression, encryption, snapshots, RAID5/6....

why would you want to embed raid5/6 in the filesystem layer? Linux has battle-tested mdraid for this, I'm not going to trust a new filesystem's own implementation over it. Same for encryption, there are already existing crypto layers both on the block and filesystem (as an overlay) level.

Because the FS can be deeply integrated with the RAID implementation. With a normal RAID, if the data at some address is different between the two disks, there's no way for the fs to tell which is correct, because the RAID code essentially just picks one, it can't even see the other. With ZFS for example, there is a checksum stored with the data, so when you read, zfs will check the data on both and pick the correct one. It will also overwrite the incorrect version with the correct one, and log the error. It's the same kind of story with encryption, if its built in you can do things like incremental backups of an encrypted drive, without ever decrypting it on the target.

Re: Linus: Don't Use ZFS

#374
post #130

Earlier quoted context omitted.

ZFS performs quite well if you give it boatloads of RAM. It uses its own cache layer, and eats RAM like hotcakes. XFS OTOH is as fast as the hardware can go with any amount of RAM.

Sort of. But no snapshots. Wanna use LVM for snapshots? 33% performance hit for the entire LV per snapshot, by implementation. ZFS? ~1% hit. I've never been able to see any difference at the workloads I run, whereas with LVM it was pervasive and inescapable.

That was with the old LVM snapshots. Modern CoW snapshots have a much smaller impact. Plus XFS developers are working on internal snapshots, multi-volume management, and live fsck (live check already works, live repair to come).

Re: Linus: Don't Use ZFS

#375
post #295

Earlier quoted context omitted.

Many of the advanced features aren't implemented yet though, like compression, encryption, snapshots, RAID5/6....

why would you want to embed raid5/6 in the filesystem layer? Linux has battle-tested mdraid for this, I'm not going to trust a new filesystem's own implementation over it. Same for encryption, there are already existing crypto layers both on the block and filesystem (as an overlay) level.

Why does ZFS do RAIDZ in the filesystem layer?

Re: Linus: Don't Use ZFS

#376
post #286

Earlier quoted context omitted.

Isn't this a problem for any over provisioned storage pool ? You can avoid that if you want by not over provisioning & checking space consumed by CoW snapshots. Also what does ZFS do if you run out of blocks ? I have actually managed to run out of blocks on XFS on thin LV and it's an interesting experience. XFS always survoved just fine, but some files basically vanished. Looks like mostly those that were open and be…

>Isn't this a problem for any over provisioned storage pool ? ZFS doesn't over-provision anything by default. The only case I'm aware of where you can over-provision with ZFS is when you explicitly choose to thin provision zvols (virtual block devices with a fixed size). This can't be done with regular file systems which grow as needed, though you can reserve space for them. File systems do handle running out of spac…

Can't you over provision even just by creating too many many snapshots ? Even if you never make the filesystems bigger then the backing pool, the snapshots will allocate some blocks from the pool and over time, boom.

Re: Linus: Don't Use ZFS

#377

"Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me." - Linus I have a strong feeling Linus has never actually used ZFS.

I've never used it. What makes it so good?

Re: Linus: Don't Use ZFS

#378
Typical Linus bullshit ...

"Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me."

Yeah, just use XFS or EXT4 without ANY data consistency ... you can use FAT32 also, similar level filesystem.

Re: Linus: Don't Use ZFS

#379
post #48

Earlier quoted context omitted.

people probably will, in a few years. rotational disks are getting cheaper and cheaper, 10TB disks in two years might cost as little as 2TB disks today (i got a 2TB disk for like 50€ off Amazon).

> people probably will, in a few years. Yes, but without the array as you stated. We have 300+ 10TB disks at our datacenter today and, ZFS is relevant at this disk count, I/O and client load. Running ZFS at small scale is raising a cow at home for a bucket of raw milk. It's more of a fun curiosity rather than a production level operation. I'd run LVM or md or something similar at home instead of a full blown ZFS setu…

The risk of bit rot is still a thing at home or in the data center. And the other niceties of ZFS like snapshots and such are a boon too. Instead of a few various layers you have one whole subsystem to do all of it: all of this you know well using it in the data center. I just use it at home too

Re: Linus: Don't Use ZFS

#380

Earlier quoted context omitted.

XFS on LVM thin pool LV should give you a very robust fs, cheap CoW snapshots, multi device support. If you want, you can make the thin pool be on RAID via LVM RAID under the thin pool. For import export, IIRC XFS has support for it and you can dump/import LV snapshots to get atomicity. For caching there is LVM cache, should be again possible to combine with thinpool & RAID. Or you can use it separately for normal LV…

Interesting combination of tools I have used independently but never as a replacement of my beloved ZFS. Never made snapshots with LVM. Always used LVM as a way to carve up logical storage from a pool of physical devices but nothing more. I need to RTFM on how snapshotting would work there - could I restore just a few files from an hour ago while letting everything else be as they are? With ZFS, I use RAM as read cha…

IIRC you can mount any of the snapshots & copy files from it without influencing the others & the thin LV itself. As for RAM caching, I'm not sure LVM would allow LVM cache residing on ram disk PV, but isin't regular Linux transparent FS access RAM caching sufficient actually ?

For some reading about LVM thin provisioning:

http://man7.org/linux/man-pages/man7/lvmthin.7.html

https://access.redhat.com/documentation/en-us/red_hat_enterp...

Post reply on HN