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.
OpenZFS 2.0
61–70 of 151 posts
Re: OpenZFS 2.0
#62I'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?
Re: OpenZFS 2.0
#63Re: OpenZFS 2.0
#64Re: OpenZFS 2.0
#65Earlier 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.
boot.supportedFilesystems = [ "zfs" ];
Both installs the necessary kernel modules and adds zpool(1) / zfs(1) to $PATH.Re: OpenZFS 2.0
#66Side 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.
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
#67Earlier 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?
Re: OpenZFS 2.0
#68Just 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.
Re: OpenZFS 2.0
#69OpenZFS is in fact a more prestigeous name and it already sounds better than ZFS on Linux.
Re: OpenZFS 2.0
#70Earlier 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.