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

121–130 of 151 posts

Re: OpenZFS 2.0

#121

Post by bmn__ »

ariabuckles wrote: post #15
anderspitman wrote: post #8

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?

Both openSUSE and [as of very recently] Fedora use btrfs by default, so btrfs support seems pretty stable these days. (But as others have pointed out, there are options for using zfs on linux, too)

Attempting to use zfs for the root partition is a huge headache because the software lives in the supplementary `filesystems` repo. https://build.opensuse.org/package/show/filesystems/zfs

1. It often happens that the main repo offers a new kernel, but the corresponding module is not ready on obs yet. This means upgrading to the latest rolling release cannot just happen at any time, but requires careful planning. This is a big inconvenience.

2. In the past dracut sometimes just failed to pick up the module for the initrd, causing a boot failure at the next system start. I could not figure out why, however this never happened with the first class supported ext/xfs.

3. The distro's boot/rescue media do not contain the driver. This means a third-party boot medium is required to go into a broken system, and repairing it when chroot is involved is now much more complicated because of the different distro.

Re: OpenZFS 2.0

#122

Post by rleigh »

nix23 wrote: post #67
curt15 wrote: post #47

Earlier quoted context omitted.

>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)

XFS is one of the only filesystems I've suffered serious catastrophic dataloss with. The other one is of course Btrfs which was and is the worst of the lot.

What was worrying was that the XFS dataloss was due an action totally out of our hands: a power outage at a substation which took out a whole area of the city. The whole datacentre lost power, and the XFS filesystems on some massive storage arrays were completely hosed. Just from power loss. It took days to put it all back from tape backups. XFS has long been known to have problems with unclean shutdowns, but total loss from a power outage is about as bad as it gets.

Re: OpenZFS 2.0

#123

Post by rleigh »

nix23 wrote: post #115
filmor wrote: post #97

Earlier quoted context omitted.

During my last >15 years of Linux usage, I had exactly the two filesystems you are advocating for here crashing on me: - XFS, long time ago, had a bug that made it lose files silently - BTRFS twice, most recently about a year ago in a super simple setup (no raid or any other fanciness). I wasn't able to recover it, after a while I at least got it to mount as ro and copied the contents away These were all on Gentoo, s…

>reiserfs That was exactly the FS that eat my data back in ~2005. Never had problems with XFS or ZFS. With Btrfs well i just use it regularly since 2 years so i cant say much, but i think Redhat chose XFS for a reason.

The reason is they hired the XFS developers from SGI. And they bought Sistina for LVM. As a result, they have been wedded to both XFS and LVM for many years now, because there is likely a combination of wanting to maximise their investment into these technologies and developing the in-house expertise to support them very well, and also in having a number of staff who are deeply committed to them and don't want to change.

At some level, they must understand that both XFS and LVM are over 25 years old, and when compared with e.g. ZFS, are completely outclassed. Their current efforts developing Stratis, which is an attempt to provide more ZFS-like functionality by extending XFS, adding LVM thin pools, and managing it all with an unholy complex combination of daemons, D-BUS and Python looks like a logical progression based upon what they have to hand in house, but a strategic mistake when it can never approach ZFS in functionality or reliability simply because these technologies can only be extended so far because of fundamental design limitations. I'll be morbidly interested to see what they can stretch XFS to do. But I won't be using it myself.

What I find really surprising here is that Linux in general, and RedHat in particular, don't have a competitive filesystem to offer. There is absolutely nothing which matches ZFS.

Re: OpenZFS 2.0

#124

Post by diegocg »

Nican wrote: post #31
throw0101a wrote: post #10

Sadly dRAID (parity Declustered RAIDz) just missed the cut-off for 2.0, but it looks like it will be in 2.1: * https://openzfs.github.io/openzfs-docs/Basic%20Concepts/dRAI... * https://www.youtube.com/watch?v=jdXOtEF6Fh0

dRAID looks really fascinating, but presentation is pretty abstract. Would it allow to add/remove drives from a pool, and allow ZFS to rebalance itself? Would be great for home use, where I have a lot of drives that I collected over the years that are not the same size. EDIT: The more I read into this, it still seems assume that all drives must be of the same size.

I don't think so. The essence of draid is that, instead of keeping a spare drive unused in case one of the working drives fail, it incorporates the spare drive to the array and uses it, but one drive worth of free space is reserved randomly across the entire array.

That way, if one disk fails, the reserved space is used to write the data necessary to keep the array consistent. Because the free space is distributed randomly across the array, the write performance of a single drive doesn't become a bottleneck.

This is unrelated to the ability to remove drives from a pool (which is difficult to support in ZFS due to design constraints)

Re: OpenZFS 2.0

#125

Post by rakoo »

phil21 wrote: post #84
koolba wrote: post #78

Earlier quoted context omitted.

Why ZFS encryption vs unencrypted ZFS atop LUKS?

I wanted to say "as someone who tends to follow the unix philosophy" and realized the irony of saying that regarding ZFS... That said, I generally agree with you in that do one thing and do it well is a laudable design goal. However, I also am very excited about encrypted ZFS for one main reason: backups. Okay two. Snapshots and backups! ZFS is absolutely amazing to use as a home NAS that does daily (or more) snapsho…

rsync.net already provides zfs receive capability: https://www.rsync.net/products/zfsintro.html

Re: OpenZFS 2.0

#126

Post by KMag »

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.

Re: OpenZFS 2.0

#127

Post by KMag »

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…

That would be an even more interesting feature for NILFS2, as I understand it, its ring buffer structure requires moving the oldest unmodified blocks as the ring buffer write frontier approaches. Any blocks that are forced to be copied are by definition old and unmodified, and need to be moved anyway, so why not recompress? AFAIK, there are no plans for compression in NILFS, but I think it's an interesting idea.

Re: OpenZFS 2.0

#128

Post by kitotik »

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.

I’ve ran the latest kernel with latest openzfs git since around kernel 4.x, currently on 5.9.11. I build inkernel as opposed to a module.

There have been a couple cases where I had to wait a week or two for compatibility fixed to get merged into zfs git, but otherwise staying up to date has not been a problem.

Re: OpenZFS 2.0

#129

Post by magicalhippo »

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

Well with ZFS I've had hardware break and still not experienced any data loss. I've had cables getting lose multiple times, I've had several disks dying[1], I've had unstable SATA controllers (hello JMicron) and plenty of unexpected power losses and hard resets.

Yet ZFS has sailed through it all with my data intact. Sure ZFS ain't bulletproof. It can get messed up. But for the most part it takes a lot of beating without a dent.

[1]: As a matter of fact, I just finished resilvering a RAID-Z1 pool in my NAS after a WD Red 3TB died after almost 7 years of 24/7 operation (barring a few accidental power outages).

Re: OpenZFS 2.0

#130

Post by nix23 »

rleigh wrote: post #123
nix23 wrote: post #115

Earlier quoted context omitted.

>reiserfs That was exactly the FS that eat my data back in ~2005. Never had problems with XFS or ZFS. With Btrfs well i just use it regularly since 2 years so i cant say much, but i think Redhat chose XFS for a reason.

The reason is they hired the XFS developers from SGI. And they bought Sistina for LVM. As a result, they have been wedded to both XFS and LVM for many years now, because there is likely a combination of wanting to maximise their investment into these technologies and developing the in-house expertise to support them very well, and also in having a number of staff who are deeply committed to them and don't want to cha…

>because there is likely a combination of wanting to maximise their investment into these technologies and developing the in-house expertise to support them very well, and also in having a number of staff who are deeply committed to them and don't want to change.

Not sure if you would risk your customers data just because of that. I never had any problems with XFS.

>At some level, they must understand that both XFS and LVM are over 25 years old

Being a User of ZFS (on FreeBSD) myself, zfs is not much younger 2006.

>and RedHat in particular, don't have a competitive filesystem to offer.

That i really don't understand too. Maybe they think for "small" stuff HW-Raid or LVM is good enough and everything bigger is Ceph or Gluster anyway.

Post reply on HN