Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenZFS 2.0

github.com

Post reply on HN
Print view View original

131–140 of 151 posts

Re: OpenZFS 2.0

#131

Post by hnlmorg »

scaladev wrote: post #93
yjftsjthsd-h wrote: post #92

Earlier quoted context omitted.

> It's still a big pain if you like to keep your kernel relatively up to date. Replacing a core system component with an out-of-repo version is always going to hurt, yes. > I switched to btrfs; it just working is worth the few extra warts over ZFS. I'm not sure I'd call "catastrophic failure and data loss" a "wart". In all my years of distro hopping, I've had 3 root filesystems become unbootable: 1 F2FS system early…

>and 2 on an openSUSE tubleweed system using BTRFS as root. How long ago was that? and have you been using other fully checksummed filesystems (like ZFS) on that hardware since then? I'm asking because if you're using btrfs without any raid features (or with simple RAID modes like 1/0) for the past several years and it breaks, if you dig deep enough into the problem, often the hardware is found to be at fault. And ex…

> if you dig deep enough into the problem, often the hardware is found to be at fault

That's not really good enough though. Next gen file systems are supposed to be resilient even if hardware fails. That's the whole point of raiding and checksumming. ZFS was very much intended to be resilient when faced with bad hardware. Heck, even in the 90s this was a known problem hence chkdsk on DOS marking bad sectors to somewhat mitigate data corruption on FAT file systems. If Btrfs only works when hardware is behaving then that is absolutely a problem with Btrfs.

As for my experience with ZFS, it's kept consistency when disks have died. It's worked flawlessly when SATA controllers have died (one motherboard would randomly drop HDDs when the controllers experienced high IOPS -- which would be enough to trash any normal file system but ZFS survived it with literally no data loss). Not to mention frequent unscheduled power cuts, kernel panics (unrelated to ZFS), and so on and so forth. I'm sure it's possible to trash a ZFS volume but it's stood strong on some pretty dubious hardware configurations for me and where most other file systems would have failed.

Re: OpenZFS 2.0

#132

Post by rcthompson »

tpetry wrote: post #112

Zstd compression with configurable levels is really interesting: You could write every block first with a level comparable to lz4 for very fast performance. And if a block has not been rewritten for some time you recompress them with a compression level allowing more compression and comparable decompression performance. So cold data (cold write, cold/hot read) will take less and less space over time while still havin…

My understanding is that for ZFS, things like this would require a mythical feature called "block pointer rewrite", the same feature required to implement out-of-band deduplication.

Re: OpenZFS 2.0

#133

Post by OJFord »

accelbred wrote: post #107
xenophonf wrote: post #83

Earlier quoted context omitted.

I've had zero problems with kernel updates on Ubuntu 20.04 with ZFS on a natively encrypted root. I followed the instructions in the wiki, lightly modified for my hardware and workload: https://gist.github.com/xenophonf/76fd44ae24772e457cb63d00c0... `apt-get update && apt-get dist-upgrade -y` works as expected. I plan to switch to a similar config on my Lenovo laptop when I upgrade it to the next Ubuntu LTS release.

Ubuntu's kernel isn't exactly keeping up to date though. I assume the person you were replying to may be following mainline. As someone using new kernel version as they are released, I'm not willing to use a filesystem that may break with a kernel update. It also seems openzfs only supports up to kernel 5.6, according the the github release. I'm on 5.9, so its not even an option.

Yeah, too many scary notes and warnings for me.

https://wiki.archlinux.org/index.php/ZFS

I would need a package that depends on zfs and provides linux-kernel at an appropriate version. Can't have something so critical break because of an upgrade, and I don't want to pin it and forget to upgrade it (also fairly anti-arch).

Re: OpenZFS 2.0

#134

Post by 1over137 »

ed25519FUUU wrote: post #57
mlex wrote: 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.

Yes, ZFS upgrades are really simple, but they are one-way, you can't downgrade after.

Re: OpenZFS 2.0

#135

Post by brnt »

koolba wrote: post #78
linsomniac wrote: post #51

Earlier quoted context omitted.

I've been running encrypted ZFS on 20.04 on my main workstation since it came out and it's worked great. Wrote up details here, it's a slight hack for encryption, no hack if you don't want crypto. https://linsomniac.gitlab.io/post/2020-04-09-ubuntu-2004-enc... A friend did a video based on my blog: https://www.youtube.com/watch?v=PILrUcXYwmc

Why ZFS encryption vs unencrypted ZFS atop LUKS?

Once you put a fs on top of something, don't you lose any guarantees of finding broken sectors when scrub?

This is why I really wish btrfs would get native encryption, but maybe my info is out of date.

Re: OpenZFS 2.0

#136

Post by aseipp »

mook wrote: post #106
takeda wrote: post #54

Earlier quoted context omitted.

Actually no, NixOS is probably easier to use than other Linuxes. It gets more difficult when you need to package something new that it doesn't have, then you have to know the Nix language and how nixpkgs work.

Interesting; when I tried it a while back it seemed like you needed to know the language to manage your configurations. Was that impression incorrect? I may have tried it far enough back that I pretty much immediately encountered packages I wished it had and tried (and failed) to package it myself, though, and got the experience mixed up…

No, you're 100% correct. Despite the prosthelytization you'll get from many died-in-the-wool users who forgot what it was like in the beginning, in order to use NixOS effectively you either need to learn Nix, or be willing to spend a lot of time on IRC asking questions, which will end up with... you learning Nix. That's the reality. I think I spent something like 3 weeks porting my server configuration from Ubuntu to NixOS, by hand, piece by piece, many years ago. Admittedly I think we're better off than we were 7 years ago, but it's still not a grand slam. Even things like basic GUI installers that can set up your filesystem don't exist! Manually screwing with partition layouts to get volume encryption isn't easy to use at all, honestly.

There are an array of flaws with the tools but, despite that, they are unbelievable powerful and you can do things in NixOS you can't dream of doing elsewhere, and it makes things like using OpenZFS or whatever pretty easy and simple. And it makes some thing far more difficult than that, nearly trivial. But only once you know what you're doing. But that's just the reality: it's an extremely powerful tool that has many rough edges. Saying it's "the easiest distro to use" is a complete joke, and I wish fellow NixOS users didn't have some weird propensity to practically lie about how good it is on that front. I say this as someone who has been a NixOS developer and user for like, ~7 years and who apparently(?!) has over 1,000 commits to the tree now, too. Trying to actually sit down at a terminal and sell unconvinced people on it opened my eyes quite a bit. It's good, but lying about what it is and isn't is a good way to burn peoples faith.

Re: OpenZFS 2.0

#137

Post by zmix »

ed25519FUUU wrote: post #60

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.

To me this sounds more like you didn't RTFM ;-)

Re: OpenZFS 2.0

#138

Post by p_l »

mook wrote: post #105
p_l wrote: post #100

Earlier quoted context omitted.

Umm, that's untrue. It's a very cleanly layered system, it just doesn't bother end user with details (as implementor, you can play with them, thus LustreZFS): there's separate SPA (block), DMU (OSD) and ZPL (FS) & ZVOL (emulated block device) layers. Compression and encryption are integrated at DMU level because that's a logical place for them. NFS actually calls OS nfs server.

That sounds about as modular as systemd: it's in theory modular, but it very much throws away the existing boundaries and has yet to see its new modules be adopted by external folks (if that were even possible, depending on interface stability). I believe that the modularity will only proof itself when external (as in, from unrelated people) projects becomes established and we see how well the original project mainta…

There's sufficiently strong dislike for systemd in the ZoL circles I moved around, because ZFS was all about making sure its rock solid and stable, while systemd has well-deserved reputation for breaking things often.

As for external clients for the layers, LustreZFS is a separate project though it had started with certain intersection of ZFS devs. However the general division of labour between layer is pretty strict (except for - now extinct - FreeBSD TRIM support), it's just that there isn't any work being done to use it outside of OpenZFS.

The boundaries are pretty clear, it's just that ZPL and ZVOL build up on all of them. Linux has /some/ related features, but nothing that was feature-parity: SPA roughly corresponds with MD/DM subsystem assuming certain plugins in use, DMU is very roughly the equivalent of OSD subsystem, but that one supports only SCSI OSD which has incompatible assumptions etc. - in fact, an OSD implementation on top of DMU should be pretty simple (main differences are due to DMU being a bit explicit on redundancy features, iirc).

Re: OpenZFS 2.0

#139

Post by rincebrain »

rcthompson wrote: post #132
tpetry wrote: post #112

Zstd compression with configurable levels is really interesting: You could write every block first with a level comparable to lz4 for very fast performance. And if a block has not been rewritten for some time you recompress them with a compression level allowing more compression and comparable decompression performance. So cold data (cold write, cold/hot read) will take less and less space over time while still havin…

My understanding is that for ZFS, things like this would require a mythical feature called "block pointer rewrite", the same feature required to implement out-of-band deduplication.

You are correct - ZFS hardcodes the assumption that data's location on disk will never change once written very deeply, and offline dedup/data migrating of any sort would require that.

(It would also be a performance nightmare - you'd have a permanent indirection table you'd need to use for _everything_, and if you've ever seen how ZFS dedup performs with its indirection table not on dedicated SSDs, you can understand why this is terrible.)

Re: OpenZFS 2.0

#140

Post by rincebrain »

KMag wrote: post #126

How's the memory consumption of ZFS without deduplication these days? I've got a couple of 4 TB drives connected to a single board ARM computer with 2 GB of RAM. I used to use btrfs, but switched to XFS after I accidentally filled up a drive and was unable to recover.

ZFS without dedup will just run slower with less RAM available for caching, up to a point (I think the lowest I've seen someone run it with ARC configured to use in recent memory is 128 MB? I believe 32 MB or so is the minimum below which OpenZFS will just ignore you if you try to tell it to use less...)

I've seen people use it as a rootfs on RPis, and have personally run it on Pis for brief occasions without encountering any RAM problems.

Post reply on HN