Live data from Hacker News

OpenZFS – add disks to existing RAIDZ

github.com

171–177 of 177 posts

Re: OpenZFS – add disks to existing RAIDZ

#171

Earlier quoted context omitted.

Sorry I said unionfs but it's actually handled by mergerfs [1], and it's all automatic. There are a whole boatload of policies [2] to control writes. I use "existing path, least free space". Once a path is created, it keeps using it for new files in that path. If it runs out of space, it creates that same path on another drive. If the path exists on both drives for some reason, my rationale is this keeps most of the…

> If it runs out of space, it creates that same path on another drive. That's not how it works. The policy picks what branch to use and then once selected mergerfs will clone the relative path as needed. With "ep " policies it will never select a branch that doesn't have the full relative path. "msp " will always rerun the check one level up in the hierarchy if nothing is found at the current level.

This is immensely helpful, thanks.

Will MergerFS mount points behave the same as on the host inside of a docker container if passed as a bind mount?

Re: OpenZFS – add disks to existing RAIDZ

#172

Earlier quoted context omitted.

I don't think Linux would like to ship a mass of code that size that's not GPLed, even if court cases say CDDL is GPL-compatible.

It isn’t compatible because it adds additional restrictions regarding patented code. The CDDL was made to be used in mixed license distributions and only affects individual files, but the GPL taints anything linked (which is why LGPL exists). Since the terms of the CDDL can’t be respected in a GPL’d distribution, I can’t see a way for it to ever be included in the kernel repo. I don’t think there’s any issue with can…

It's a little unfair to blame it on GPL. If ZFS was MIT/BSD/etc licensed, it could be brought into the Linux repository just fine. CDDL explicitly doesn't let that happen, by saying "Source Code form must be distributed only under the terms of this License". That only is harsh.

Re: OpenZFS – add disks to existing RAIDZ

#173
post #47

Earlier quoted context omitted.

I think I would advise against a direct mirroring -- instead, I'd do sync-every-24-hours or something similar. Both schemes are vulnerable to the (admittedly rarer) errors where both drives fail simultaneously (e.g. mobo fried them) or are just ... destroyed by a fire or whatever. A periodic sync (while harder to set up) will occasionally save you from the deleting the wrong files which mirroring doesn't. Either way:…

> A periodic sync (while harder to set up) will occasionally save you from the deleting the wrong files which mirroring doesn't Which ever solution for disks you end up with, you should definitely always be using something that keeps around periodic snapshots.

Agreed, but even that is vulnerable to software bugs around snapshotting itself.

Re: OpenZFS – add disks to existing RAIDZ

#174
Lack of this feature has kept me on Synology and their SHR-system.

I can just slap in any drives of any size and it'll just adapt. As long as the new drives go in an empty slot or are bigger than the previous one, I get more space. Zero CLI commands needed.

Now get this feature in unraid or TrueNAS and I'm switching.

Re: OpenZFS – add disks to existing RAIDZ

#175

Earlier quoted context omitted.

It isn’t compatible because it adds additional restrictions regarding patented code. The CDDL was made to be used in mixed license distributions and only affects individual files, but the GPL taints anything linked (which is why LGPL exists). Since the terms of the CDDL can’t be respected in a GPL’d distribution, I can’t see a way for it to ever be included in the kernel repo. I don’t think there’s any issue with can…

It's a little unfair to blame it on GPL. If ZFS was MIT/BSD/etc licensed, it could be brought into the Linux repository just fine. CDDL explicitly doesn't let that happen, by saying "Source Code form must be distributed only under the terms of this License". That only is harsh.

if the kernel was MIT/BSD/etc licensed ZFS would be allowed in the kernel just fine too. but only one of the licenses is infectious and requires things of the other sources.

it's definitely a GPL issue more than a CDDL issue

Re: OpenZFS – add disks to existing RAIDZ

#176
post #169
post #165

Earlier quoted context omitted.

My reasoning for using mirrored vdevs was more about the ease of expanding the storage than the redundancy.

We just used RAID6... expanding by more drives is easy while keeping data waste low and the "we want to put bigger drives now" case isn't all that problematic considering that what you save you waste on low efficiency of RAID1 setup. We did had a big case so we just ran 2xRAID6 setup and that one time where it was needed we just replaced to bigger drives one by one, while using the removed ones as spares for other ma…

Yeah mine is a home NAS, not a professional deployment. At first I was a bit disappointed at losing half the storage due to using mirrors but honestly it’s not a big deal considering the prices I managed to find on the drives. And I also wanted to expand at my own pace. The drive I recently used to replace the dead 4TB drive cost me 110€ and it’s a 10TB drive.

I got 2 so I’ll also replace the sibling of the dead 4TB one.

Re: OpenZFS – add disks to existing RAIDZ

#177

Earlier quoted context omitted.

It's a little unfair to blame it on GPL. If ZFS was MIT/BSD/etc licensed, it could be brought into the Linux repository just fine. CDDL explicitly doesn't let that happen, by saying "Source Code form must be distributed only under the terms of this License". That only is harsh.

if the kernel was MIT/BSD/etc licensed ZFS would be allowed in the kernel just fine too. but only one of the licenses is infectious and requires things of the other sources. it's definitely a GPL issue more than a CDDL issue

GPL predates CDDL; CDDL authors were well aware of GPL; CDDL authors chose to make the license different from existing commonly-used open source licenses. Ask why...
Post reply on HN