LOL, obviously Space-cursor-xAI-musk-imperial-holdings-inc is providing them compute. They either _can't_ cut them off, or they know not to bite the hand that feeds them.
I never said most people. But it's not uncommon. I personally find it ridiculous, and hold onto my phone until it's unusable, but plenty of people in middle class Australia seem convinced that they need the new one whenever it comes out.
QNAP unforgivably uses a proprietary version of ZFS with their own extensions that are not compatible with mainline OpenZFS.
It can only zfs send/receive to other QNAP devices. While your data is protected like any other ZFS system, it is _NOT_ interoperable. You can not take a zpool out of a QNAP system and access it on another system with ZFS.
I discovered this painfully the hard way, and won't buy from them again, unless I plan to wipe the software and run something open.
I think the ZFS changes were due to needing a way to allow qnap systems to expand zfs pools. The raidz expansion features in openzfs probably took too long for qnap to wait.
OpenZFS released the zpool expansion as stable last year. Hopefully QNAP is charting a path to allow their users to migrate from their fork to OpenZFS, though of course these kinds of things take time to develop. I would be really worried if they are diverging further from OpenZFS rather than converging.
Last I looked at their releases of code, they had branched from ZFS before it became OpenZFS, and had a lot of proprietary extensions beyond just the reshaping (from memory, they implemented encryption differently, as one example, and I think they had one or two checksums that I assume were because something they shipped had hardware support for it?) so I wouldn't hold out hope that their goal is to rebase on OpenZFS unless they announce something to that effect.
Nah, I doubt they're going to rebase to openzfs. There's too much divergence and I don't see them putting the time to write something that converts their zfs format to openzfs without an extremely good reason.-
> Hopefully QNAP is charting a path to allow their users to migrate from their fork to OpenZFS
This kind of migration is the stuff of nightmares. The main job of a NAS is to keep the data safe. A file system migration that works in every one of those corner cases present in the wild is statistically unlikely. The kind of bad publicity this can bring is what can sink a company. The only way I'd ever do this is by starting fresh on different storage and replicating the data.
There’s literally thousands of petabytes running on it in the wild, and it has continually proven to be one of, if not the most reliable filesystem, on the planet.
Joe blow running a beta release on his raspberry pi complaining about ram usage isn’t indicative of reality.
There are very real reasons to use ZFS instead of the oldschool Linux block device sandwich.
mdadm+luks+lvm still do not quite provide the same set of features that ZFS alone does even without encryption. Namely in-line compression, and data checksumming, not to mention free snapshots.
ZFS is quite mature, the feature discussed in the article is not. As others have pointed out this could have been avoided by running ZFS on top of luks and would have hardly sacrificed any functionality.
> mdadm+luks+lvm still do not quite provide the same set of features that ZFS alone does even without encryption. Namely in-line compression, and data checksumming, not to mention free snapshots.
Sure, but LUKS+ZFS provides all that too, and also encrypts everything (ZFS encryption, surprisingly, does not encrypt metadata).
As this article demonstrates, encryption really is an afterthought with ZFS. Just as ZFS rethought from first principles what storage requires and ended up making some great decisions, someone needs to rethink from first principles what secure storage requires.
It's a little weird to denounce the "block device sandwich" and then say that they should have used... a variation of the block device sandwich.
> There are very real reasons to use ZFS
I feel like, for the types of person GP is talking about, they likely don't really need to use ZFS, and luks+md+lvm would be just fine for them.
Like the GP, I have such a setup that's been in operation for 15-20 years now, with none of the original disks, probably 4 or 5 full disk swaps, starting out as a 4x 500GB array, which is now a 5x 8TB array. It's worked perfectly fine, and the only times I've come close to losing data is when I have done something truly stupid (that is, directly and intentionally ignored the advice of many online tutorials)... and even then, I still have all my data.
Honestly the only thing missing that I wish I had was data checksumming, and even then... eh.
Run enough disks long enough and you'll find one that starts returning garbage while telling the OS everything is ok.
First time I had it happen was on a hardware raid device and a company lost 2 and a half days worth of data as any backups from when it started had bad data.
The next time I had it happen is using ZFS and we saw a flood of checksum errors and replaced the disk. Even after that SMART thought it was perfectly fine and you could send commands to it, you just got garbage back.
reply