Live data from Hacker News

OpenZFS 2.0

github.com

61–70 of 151 posts

Re: OpenZFS 2.0

#61

Side note, they really should have in big-bold letters "DO NOT ENABLE DEDUPLICATION UNLESS YOU HAVE A TON OF RAM!" on their readme. That was a huge mistake on my part. The ram requirements are VERY high for good performance. I realized how bad the performance was when it took about 2 hours to delete 1000 files.

That's not new with 2.0 though. It's forever been the case with ZFS. Everything that discusses dedupe basically says: 'don't use it'.

Re: OpenZFS 2.0

#62

I'd love to get rid of my FreeNAS VM and run ZFS directly on my Linux desktop, but having to mess with the kernel has kept me from attempting it so far. Maybe I'm worrying about nothing. btrfs seems like the main alternative if you want native kernel support, but when I checked a couple years ago there seemed to be a lot of concerns about the stability. Is that still the case?

I use btrfs on both servers and laptops without a problem these days. This wasn't the case almost a decade ago, though, when I got bit by its then-instability.

Re: OpenZFS 2.0

#65
post #44
post #32

Earlier quoted context omitted.

Is there a guide for this? Sounds interesting!

For instance, I have: fileSystems."/zfs/media" = { device = "tank/media"; fsType = "zfs"; }; in my hardware-configuration.nix. tank/media is defined as using a legacy mount-point or whatever the ZFS terminology is. Done. ETA: I mean, I had to do all the gruntwork to get the pool built, yeah. But once it was defined, getting it mounted and all the kernel bits and bobs set was trivial like that.

In addition, if you just want to play around with it:

    boot.supportedFilesystems = [ "zfs" ];
Both installs the necessary kernel modules and adds zpool(1) / zfs(1) to $PATH.

Re: OpenZFS 2.0

#66

Side note, they really should have in big-bold letters "DO NOT ENABLE DEDUPLICATION UNLESS YOU HAVE A TON OF RAM!" on their readme. That was a huge mistake on my part. The ram requirements are VERY high for good performance. I realized how bad the performance was when it took about 2 hours to delete 1000 files.

It does already say that. This is what it says:

Deduplication is the process for removing redundant data at the block level, reducing the total amount of data stored. If a file system has the dedup property enabled, duplicate data blocks are removed synchronously. The result is that only unique data is stored and common components are shared among files.

Deduplicating data is a very resource-intensive operation. It is generally recommended that you have at least 1.25 GiB of RAM per 1 TiB of storage when you enable deduplication. Calculating the exact requirement depends heavily on the type of data stored in the pool.

Enabling deduplication on an improperly-designed system can result in performance issues (slow IO and administrative operations). It can potentially lead to problems importing a pool due to memory exhaustion. Deduplication can consume significant processing power (CPU) and memory as well as generate additional disk IO.

Re: OpenZFS 2.0

#67
post #47
post #20

Earlier quoted context omitted.

No, they have ARC and ARCL2, if you want the traditional thing go to NILFS2 or BTRFS or in the future XFS (when they have full check-summing).

>in the future XFS (when they have full check-summing). Is this actually planned?

YES! Step by step and keep XFS as stable as it is (the most trustworthy linux FS of them all)

Re: OpenZFS 2.0

#68
post #25

Just built a FreeNAS system over the past couple weeks and finished doing burn-in tests of my hard drives, wonder if I should wait and see how to install OpenZFS 2.0.0 before I create my storage config.

Aren't ZFS upgrades to existing vdevs really simple? I don't see any reason why you need to wait.

They certainly seem to be within OpenZFS over the past few years.

Re: OpenZFS 2.0

#69
post #64

OpenZFS is in fact a more prestigeous name and it already sounds better than ZFS on Linux.

If you get on the calls, you’ll find zero hostility across the operating systems devs. The focus is on OpenZFS, with the Linux branch gradually becoming baseline for the FreeBSD work as well. Illumos ( where OpenZFS originated after Illumos was formed post the OpenSolaris shutdown) hasn’t moved to this baseline yet due to the significant OS level differences and instead code is pulled between the “branches” as needed. The collaboration happens via email and regular calls.

Re: OpenZFS 2.0

#70
post #29

Earlier quoted context omitted.

Hey everyone has a different taste, but vdevs, datasets, and pool are for me much more logical than lv's and lg's (pun was NOT intended).

but thats not really btrfs, thats LVM. I use BTRFS directly on physical disks and dont use pvs, vgs or lvs.

well then call it volumes and vdev's?...i love zfs's layering.
Post reply on HN