OpenZFS v2.0.0 targets Linux and FreeBSD – shame about the Oracle licensing worries The OpenZFS project, formerly called ZFS on Linux, has released version 2.0.0 with major new features. The previous release was version 0.86 in October. Both Linux and FreeBSD are supported. ZFS is approaching 20 years old. It was developed in 2001 by Sun Microsystems, and open-source code was released with OpenSolaris in 2005 …
if you use OpenZFS as intended, why is there a legal issue?
The licensing issues have to do with GPL as I understand it. Just go with the CDDL or whatever it is that the OpenZFS is licensed under, and it's no problem. If you need to NOT have the "tainted kernel" warning, all you need is a "BLOB wrapper" kernel module that allows building for any kernel config, then link in the CDDL-licensed re-distributable pre-compiled BLOB when you install it locally. Simple. (a 'build from source' package could do this quickly and efficiently)
YOU (the end user) can do whatever you want with GPL'd or CDDL'd code, if you're NOT distributing it. The people who have to "sweat the load" over licensing are the people who DiSTRIBUTE the code. As far as I understand it there's no restriction for ANY kind of commercial usage with the OpenZFS code. So what's the probem?
(maybe it's "GPL purity", an UN-realistic expectation)
Oracle seems to have managed to let the licensing problem stand long enough to make it irrelevant: Scaling file systems has gone through a few paradigm changes in these 20 years, so that the target market for ZFS is ... not that big any longer.
Add to that some arcane rituals needed to be performed if you run into one of those nice little 'cannot mount ZPOOL' siutations and it is just no longer relevant except for some rare edge cases.
I'd have happily invested in it 20 years ago. Even 15. Buto today? Nah.
Even as a private citizen I don't use ZFS with Linux because of the licensing conundrum. I can't recommend a business do it. If ZFS ever makes it into the main-line kernel then the weight of the Linux Foundation will be behind it.
Remember, is Oracle we are talking about. They ship their code to customers with features enabled they never paid for and then go back and sue them after they compile it.
It's not a conundrum. It's a bogeyman. People see the name of Oracle, stop using their brains, then run around in circles while flailing their arms and screaming.
There's *plenty* of FOSS code from Oracle that's used without a second thought, like in MariaDB. So why ZFS was chosen as the poster child of Oracle deviousness boils down to a few noisy GPL zealots hatred of a license that's FOSS, but of a different religion.
"It's not a conundrum. It's a bogeyman. People see the name of Oracle, stop using their brains, then run around in circles while flailing their arms and screaming"
Hold on; this is exactly the same Oracle Corporation that both routinely resorts to litigation in the courts and that investigates its own paying customers for license and payment compliance.
I will not even down vote you for that.
You can deny reality all you want to. However, the historical evidence is there to support an extreme amount of caution in this case. Until there is a body of historical evidence to the contrary, that is to say showing that Oracle and Larry Ellison have both changed their ways, I will not change my opinion.
Calling myself and others Zealots is easy to do without knowing us, but since this is the internet all you have to do is click my name to read my post history. Which you didn't do because you don't care one way or the the other about this matter. You just care about what you are paid to post. Just like any good Sock Puppet account holder.
So you and the rest of the Sock Puppet Army can:
Kiss
My
Ass.
Oracle is known to be very litigious. If RedHat, Apple, Canonical, iXSystems, Nexanta, Delphix etc. etc. have done anything wrong in shipping their own ZFS implementations (or ones based on the Open Source forked under de CDDL) in their products, why hasn't Oracle sued them?
"If RedHat, Apple, Canonical, iXSystems, Nexanta, Delphix etc. etc. have done anything wrong in shipping their own ZFS implementations (or ones based on the Open Source forked under de CDDL) in their products, why hasn't Oracle sued them?"
Because OpenZFS has not yet officially and formally been included within the Linux kernel itself. That's when Oracle is likely to start to take an interest and see what potential legal options they might have.
I understand the nuances on both sides. However, that isn't going to be more than a minor speed bump to my personal use, which (I know, I know) isn't the issue. Doesn't help non-techies but I'm hesitant to even consider recommending its use by them anyway. OpenZFS is very techie.
I wish LLL's passing would change Oracle behavior, but given the history of IT, it'll become even more loathsome.
The thing is, why wait until a fairly small non-profit outfit such as the Linux Foundation has included it in its kernel when giant corporations with very deep pockets are much more interesting targets?
Apple included their own ZFS implementation for a while in their OS as a secondary (and read-only by default) file system. They chose to develop their own filesystem (APFS) in the end but ZFS was included in their binaries and on their install DVDs for a bit. Apple has unfathomably deep pockets so if it’s money they are after Oracle could have sued Apple years ago. The risk for Oracle might have been that Apple would spend an amount smaller than their catering budget and use it to buy all of Oracle outright.
Canonical will have more money than the Linux Foundation, they offer and support ZFS on Linux (and soon OpenZFS) why not go after them?
Netflix runs their infrastructure on FreeBSD, I bet they use FreeBSD’s ZFS implementation for that. Why not go after Netflix?
The Sony Playstation 5 runs on an adapted version of FreeBSD 12 (i.e. with ZFS binaries included in the base installation). I wouldn’t be surprised if they use a simplified installation of FreeBSD’s ZFS implementation to allow for the easy and automated addition of extra storage that the PS5 allows. Why not go after Sony?
Dozens of multimillion dollar storage appliance companies depend on a flavour of ZFS in their products. Why not go after them?
Probably many hundreds of cloud storage and back up service providers use a flavour of ZFS. Why not go after them?
Those are the targets that Oracle could go after. The bigger question is, on what legal grounds?
The original ZFS code was released in 2005 by Sun under the CDDL license, a well known open source license very similar to the Mozilla Public License and recognised by the Open Source Initiative and the Free Software Foundation. When Oracle bought Sun five years later, Oracle’s further contributions to their own ZFS implementation were never open sourced but by then various forks of the open sourced code were already way ahead of Oracle and the rumours are that the entire Oracle department that used to work on ZFS has since closed down.
All the work on OpenZFS by third parties, both by commercial companies and non-profit initiatives is released under the CDDL license. OpenZFS 2.0 is a combination of open sourced code from Illumos, FreeBSD, ZFS on Linux, iXsystems, Nexanta, Delphix and a number of other companies and organisations. All these parties (and Sun in 2005) have willingly and knowingly open sourced their code for other people to legally use.
I get that Linus sees the GPLv2 as incompatible with the CDDL license and as far I know he is right. To use a potential legal threat from Oracle is a straw man, though.
As long as you ship the items separately and merge them on the final system, CDDL and GPL are ok (if uneasy) bedfellows
if you ship a premerged system, that's when you're setting yourself up as a target
CDDL was deliberately written to be incompatible with GPL at the insistentce of Sun engineers who didn't want to see their product incorporated into Linux. It works fine with BSD, which is where IxSystems got their start
The axis on the charts don't start at zero, so it makes it look like gzip is ~20x slower than zstd, when it is only 3x slower. Plus, the main comparison would be lz4 or lzjb, not gzip.
zstd looks awesome enough without having misleading chart - great performance and compression ratio.
I find that confusing about almost all charts today. Granted I do not follow this anymore, but something I do not know or haven't seen is a fair comparison of the Reed Solomon performance of all these filesystems that use it. Last I saw (~13 years ago), the RS algorithm was the main goto when something actually went wrong, not just in happy-time usage. Just having an entire drive crash and saying "swap it and rebuild" isn't your worse case scenario, it's your best because RS has proven to have some not so obvious faults (or at least did).
Reed Solomon encoding was the standard for a software component of GPFS (now Spectrum Protect) called GPFS Native Raid. It was used in large scale filesystem deployments in the IBM Power 7 775 supercomputer and the SONAS network storage device that IBM used to sell.
The advantages are that given sufficient numbers of physical volumes (and the '775 that I looked after had thousands of spindles), when using a set where a symbol is spread over 11 blocks, of which any 8 can be used to recover the data, rebuild time was hugely reduced, and each raid set could lose up to 3 spindles before there was any danger of data loss.
On top of that, if you leave say 5% of a large raidset empty, you can start reconstructing the data as soon as a disk fails, (similar to hot-sparing), and can pace it so that there is no burst of activity when a disk is replaced. If a second disk fails during the rebuild, you can then up the priority of the rebuild process to get back to maximum resilience faster.
There were many other features including high disk density, striping for performance, and hot disk swap that was facilitated by this feature. All in all, the RS encoding did not cause any problems, although sometimes the physical disk management did.
Yes, a simplified explanation is that ZSTD offers Gzip style compression ratios at lz4 style speeds. Also, the lz4 version that was included in ZFS many years ago is quite an old version. However, for compatibility reasons it was never updated to a newer version because all checksums for existing dedup tables would suddenly be incorrect. Quite a pain if you have a 400 terabyte system using ZFS dedup.
Compression in OpenZFS is not just used to fit more data on your storage devices, it's also a very noticeable speed gain. Compression and decompression with lz4 or Zstd is so blazingly fast that it's almost always faster to compress data before sending it to a storage device because it's less data that needs to transferred. Even using fast NVME drives.
Compression and decompression with lz4 or Zstd is so blazingly fast that it's almost always faster to compress data before sending it to a storage device because it's less data that needs to transferred. Even using fast NVME drives.
That last sentence is good to know (and bloody impressive). It makes me wonder whether we'll end up with compressed main memory, decompressed as it's loaded into the cache levels.
The thing is, even older CPUs run rings around NVME drives when it comes to moving data, as long as it's in small chunks from cache. The speed difference between getting 32k off an NVME drive into a CPU or getting the same amount from Level 1 cache into a CPU is so big that it makes an NVME drive look glacial.
A well-designed compression mechanism optimised for speed (and less for compression ratio) makes use of the insane speeds available inside the CPU package to operate faster than NVME speeds.
Much of this is academic anyway as many people will only connect their NAS using at most 10GbE and that is limited to 1250 MB/s, below ZSTD speeds. Your network is more likely to be the bottleneck than the compression speed.
great performance and compression ratio.
I use ZFS's compression feature a LOT on FreeBSD workstations and servers. It's ok for binaries, really good for text (like source and e-mail repositories). Additionally for source and e-mail storage on the server I use automatic data replication (basically 2 copies of the stored data). With compression, the replication isn't that much of a 'hit'.
on a fairly large project's source tree (which had some compiler output files in it) "du -A" (actual reported size, not on-disk size) showed a total file size of 1.9G, but without the '-A' (actual on-disk size) it showed 593M. That's using the native ZFS compression. Overall in the 'catch all' source tree, with lots of already-compressed tarballs, svn and github metadata, and other binary files, there was a size reduction of about 25% (14G vs 19G). So YMMV on that one. [but I nearly always use compression anyway, especially for archived files and text].
I'm pretty sure that compression works poorly for downloaded cat videos and compressed audio, so as would be expected I turn it off on those directory trees. It's just a setting. (you create it as a separate zpool that's part of the main zroot, basically, and set up compression/replication etc. for that particular pool. easy enough, but a little planning helps).
Back in the winders 'stacker' days (and when NTFS finally got compression) I confirmed that compressed data often read faster than uncompressed due to drive speeds, so it made sense to just compress the entire drive by default. I don't know if that's still the case with spinny drives (i.e. compressed data reads faster), but it may be a performance hit for SSDs. Still it seems to be fast enough as far as I'm concerned, using large spinny drives.
The Wall Street Journal used that trick for ... well, ever. "OMG, look at that stock price volatility!" but when you look at the axes you see that the chart maker has accentuated tiny changes to jibe with whatever point the accompanying article is trying to make. As Oracle used to be quite rabid in their disallowing independent benchmarks to be published without their consent, one might as well assume that that chart came from Oracle itself.
I'm not sure if it was considered "supported" back in 16.04(2016) but am currently running several 16.04 systems with zfs with packages from ubuntu.
Perhaps the 19.10 innovation with zfs was installer support? I recall reading news about that but don't remember the version specifically.
https://packages.ubuntu.com/xenial/zfsutils-linux
No special setup, just using zfs in some cases where the compression is helpful, as the back end SAN storage is old enough that it doesn't support inline compression(no zfs on root, just extra file systems after system was installed already)
Haven't personally used any Ubuntu that wasn't LTS since 10.04 so don't know how much further back than 16.04 built in zfs got.
The *ONLY* problem with the license is that it is not viral and thus not compatible with the beloved GPL. The OpenZFS license meets 100% of the definition of open source and thus there is no *REAL* issue with using it on Linux or any other open source OS (I am a FreeBSD user). GPL has one fundamental flaw which that makes it in the eyes of anyone who is not in the Cult of Stallman (not the only or even the first open-source philosopher/champion) "evil". That flaw is it makes it *IMPOSSIBLE* to be a independent developer (i.e. not backed by a large organization or foundation) and make a living from writing free open source software (which from every standpoint, except for making a living if you use GPL, is the right way to do software development). Before any of the members of the Cult point to being allowed to offer "support and other services unrelated to the code it self" this is *NOT* making a living from programming it is making a living from doing everything else but programming (again something that only well backed developers can do). Donations are also not "making" a living they are only charity and again only available to a project that has reached a critical mass user base (which often requires the marketing muscle of a corporate sponsor and thus is not available to independent developers).
Non-viral open source licenses such as the one Oracle uses and the BSD license do not have this flaw because they do not prevent me from reusing my open-source code in a paid project (or even to customize the code for a specific user who just happens to be willing to pay for it). Noting here keeps the main body of the code from being open-source. Viral licenses like GPL are designed specifically to not allow this and thus are really, at the end of the day, a weapon of large corporations against small developers. I am sure this is what Stallman originally intended but it is the result and Stallman is too much of a idiolog to admit that thus we are now stuck with his error and its stifling of real innovation.
For more see https://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.html
A good rant - based on a false premise.
To be clear, you as a programmer can do what the hell you want with YOUR code. If you want to contribute that code under GPL to a project then that's fine - it does NOT stop you using that code elsewhere or licensing it under commercial terms to someone. So, for example, you can contribute code to a GPL project under GPL, and also licence it to be used (not under GPL) to someone who wants to build it into a closed and proprietary system. Or you could build that same code into a non-GPL project of your own.
Putting something out under GPL does not in any way whatsoever stop you also putting it out under any other licence you want.
But what it does stop you doing is taking someone else's work that's under GPL, and using it/re-licencing it under lesser terms than the GPL. History is littered with examples of commercial companies taking software that's been made freely available by someone, and then (with zero payment and possibly zero credit) building that into a commercial closed offering.
And of course, what this comes down to is that you have the freedom to ignore the GPL and not use it. But if you choose not to contribute into the (GPL) pool, don't be offended if those that do contribute choose not to let you steal their work. Or put another way, you are only obligated to have anything whatsoever to do with GPL code if you choose to use someone's efforts which they chose to GPL.
And if you do see a bit of GPL code that you would like to use not-under-GPL then that is also possible. All you need to do is ask the copyright holder for permission - which they are free to grant or not (it's their software remember), and they may or may not charge you for that (it's their software remember). So there isn't actually a block on using GPL code in your proprietary software - you just have to legally licence it from the copyright holder, in just the same way as if it was commercial code. The difficulty comes when it's a non-trivial bit of code and it's hard to work out who owns copyright on which bits.
A bad rant, that completely misses the point.
ZFS could not use the GPLv2 because of its inception on OpenSolaris, and then ports to other OS such as FreeBSD, where the GPLv2 could not be used.
Do note the irony that if Sun had used the GNU GPLv3 (a distinct possibility, they said had it been available earlier, they'd have considered it as it included patent protection the v2 lacked), it would *still* be considered incompatible for Linux use by the zealots.
You know very well Sun had speciffically and purposedly chosen a license incompatible with GPL because they wanted to have a small string attached. I don't buy the post-factum argument that they would have used GPL v3. Besides that, ZFS is available on Linux but not distributed from the same source.
By the way, GPL v3 came out because there were already people trying to poke holes in v2 and FSF had to close some of the loopholes. If GPL v2 was already too restrictive for the taste of Sun, I don't see them finding v3 more palatable.
>>> You know very well Sun had speciffically and purposedly chosen a license incompatible with GPL because they wanted to have a small string attached.
What the hell? They chose a less-restrictive license than the GPL, yet you blame them for the GPLs restrictions?
I never realise my code under the restrictive GPL - does that mean I have an ulterior motive too?
I totally agree on this. If after all this years we still have people attacking GPL under false premises like those mentioned by sarek1024, this is no longer proof of innocence or stupidity. It's plain bad faith mostly driven by a hidden agenda.
It is beautifully resumed by the phrase 'you as a programmer can do what the hell you want with YOUR code'. Those downvoting your post either can't read properly or have no clue whatsoever on what they're talking about
>>> I totally agree on this. If after all this years we still have people defending the GPL under false premises
FTFY.
>>> It is beautifully resumed by the phrase 'you as a programmer can do what the hell you want with YOUR code
That's what Sun did with ZFS, yet you and the people quoted in the article are complaining... But GPL guys are the good guys, right? Sigh.....
If after all this years we still have people defending the GPL under false premises
What false premises ?
Does the GPL somehow hide what you can and can't do with code released with that licence ? No
Is it in any way unclear ? No
Does it in any way stop you using it in any way you want ? No
Does it in any way say what you must do with YOUR OWN CODE ? No
What is does say is very clear. You can use, or not according to your choice, GPL code. You can modify it, you can create derivative works, you can incorporate it into other works. The ONLY thing it (well GPLv2 at least) says is that you cannot grant anyone you distribute that GPL code to any lesser rights than those. Put another way, what you cannot do is take GPL code, modify it/derive from it/incorporate it onto other works and redistribute it without giving anyone you distribute it to the same rights<period>.
Of course, what that does mean is that you can't take a load of GPL code, build a closed commercial system with it, and then sell it as a closed proprietary system. If you want to do that then you have choices - but don't moan that people have decided not to allow you to make a fast buck by using their hard work without passing on the benefits of that in the same way that they were given to you. So either do your own work, approach the original creators and negotiate a licence that allows you to do what you want, or work out how to correctly link to the GPL'd modules ina way that leaves your own code separate (depending on what you want to do, that may well be practical).
But don't falsely accuse the GPL of being something it isn't just because it doesn't allow you to make a fast buck on the back of someone else's work. You absolutely ARE allowed to make money writing code. You just aren't allowed to make money by ripping off others' code in a way they aren't happy with. Anyone complaining that the GPL prevents them making money from their code is wanting to do exactly that - rip off others' work.
As to ZFS. I'm pretty sure Linus isn't complaining - he's simply stating an opinion that the licence the ZFS code comes with isn't compatible with how Linux works. In fact, he's supporting the principle that the originator of a piece of code can decide what licence terms they want to apply to it - and honouring that choice. That the two are not compatible is indeed unfortunate from the PoV of incorporating ZFS into Linux, but then it's also unfortunate that if I buy a piece of equipment from (say) North America then it probably doesn't come with the right voltage requirements and plug to plug it straight in in the UK.
With that analogy, you could say that I could simply buy (or make, perhaps even starting making and selling them) a converter that provides a US style socket with the right voltage on it. Then the US equipment can just plug in - and that's what some people have suggested, a "converter shim" that takes one plug on one side (with one licence) and converts to a different plug on the other side to plug into the Linux kernel (with a different licence). By that analogy, Oracle have shown that they consider details of the interface (e.g. dimensions of the socket, and how a plug interacts with it) as being under their non-permissive licence - c.f. the ongoing case with Google about interface header files. That may or may not be valid - we'll have to wait and see. But what Linus has said is that given the cost of dealing with "Oracle parking it's tanks on your lawn", he doesn't want to take any risk. I can see his point, it is very expensive to successfully defend such an action, even more expensive to lose.
"steal your work"? Do you work for the MPAA?
The GPL is a horrible sticky license - the sort lawyers love.
If anyone wants to use your code, they still can, by linking to it as a library. It just gets more fiddly for distribution.
Other licenses, such as cddl and bsd exist as there are people that want the best code out there.
The Internet would never have hairbrush if it had to start GPL
Are you on Oracle leagal team ? Cause if you're not I can tell you what to do with your opinion unless you're the one that will foot the bill when big red O lawyers will park their tanks on my lawn.
It seems you don't even know the difference between using and distributing code and still, you rant about suitability of different type of licenses.
And lastly, no, the flaw is that it prevents you from making a living on the back of GPL licensed code. Develop your own code and pick your favorite license. Viral licenses are preventing you to reuse open-source code written by others. If it's your own code, you'd know by now that you can dual license it. This is what Stallman intended and it has been working like that for more than two decades and this is what makes for the difference in adoption of Linux versus *BSD. So, if you don't like GPL just don't use it, nobody is forcing you to use it.
Compatibility has been a bit of an issue in the ZFS space because there were so many different ZFS implementations around that didn't all support the same features. That will change after the release of OpenZFS 2.0, though, as practically everyone working on some variant of ZFS has now come under the OpenZFS umbrella and donated their code to v2.0.
That means that, once everyone has replaced their existing ZFS implementation with the OpenZFS 2+ version, you could take a set of drives from a TrueNAS device and read them on your Ubuntu desktop, or take a drive out of your FreeBSD server and read it on your Mac. You could take a set of drives out of your Joyent system and read them on Windows.
I am just hoping that XigmaNAS doesn't wait until the release of FreeBSD 13 in March before upgrading to OpenZFS 2.0 but go down the kmod route before then.
>>> Linux watcher Michael Larabel commented: "OpenZFS 2.0 is a hell of a release – it's just too bad many Linux distributions and upstream kernel developers aren't backing it due to license incompatibilities with the upstream kernel and Oracle having not taken action to improve that situation."
Forgetting for a moment that they released their code under a LESS restrictive license, why should they jump through hoops due to GPL problems? Those using the restrictive GPL are the ones who need to modify their stance,.
How would GPL advocates react to the comment about the Linux kernel ".... Developers aren't backing it due to licencing incompatibilities, and Linus having not taken action to improve that situation"?
I have used Ubuntu LTS for a couple of years, but I am now migrating back to Solarish. The main reason is that Ubuntu LTS is so fragile, frequently the updates are problematic and cause lot of problems. It is also impossible to roll back the changes in some cases. This causes reinstalls. I thought that LTS were supposed to have stable and well tested updates, but apparently, not. On Solaris it is easy to rollback an update with Boot Environments because it just ZFS snapshots the OS, so you just have to reboot. This feature is supposed to arrive to Ubuntu 2020.10. So I tried Ubuntu 2020.10 with OpenZFS v0.8.4 - and it was problematic too. First of all, this rollback feature does not work as advertised, it is experimental and not rock solid. Google this. But worse, OpenZFS renders ZFS disk totally unusable because it messes up the ZFS disks. So I cannot stay on Linux anymore, I cannot trust OpenZFS. It provenly messes up disks. What more does it mess up? Your data? The reason I use ZFS is because my data is protected, but OpenZFS is not trustworthy. It is obviously broken.
Try this. Format a disk using Solaris 11.3, which has the reference implementation of the true ZFS, and format the disk to version 28 which all ZFS derivatives support. Now, import that disk into Ubuntu 2020.10 with OpenZFS v0.8.4 and copy some data to the disk (I used zfs send recv). Then, try to import that disk into Solaris 11.3 again. This will fail. Solaris will complain that the disk is UNAVAIL and I have to use backup. Obviously, OpenZFS messes with the Solaris zfs disks, making them totally unusable. Therefore OpenZFS is not compatible with ZFS. And there are other problems as well with OpenZFS, for instance it adds one "zpool import..." entry every time you boot Ubuntu 2020.10 and OpenZFS v0.8.4. After a while you have 100s of unnecessary lines in "zpool history". And later, 1,000s of entries in "zpool history".
If you use a ntfs-3g driver under Linux, which messes up your Windows disk so much that Windows cannot read the disk - then you have a problem. It would be misleading to call it ntfs-3g because it is not compatible with ntfs.
I think OpenZFS should be renamed and the "ZFS" part should be omitted, because it is not compatible with ZFS. It is another filesystem, based on ZFS but not compatible with ZFS. It can not properly handle ZFS disks without messing them up.
However, Ubuntu OpenZFS can read and handle OpenZFS and also ZFS disks. Solaris ZFS can only handle ZFS disks, but no OpenZFS disks - and if you use your ZFS disk under Ubuntu, OpenZFS will mess up your ZFS disk so much you cannot use it anymore under Solaris.
Have you upgraded the pool when you opened it in an OS that uses OpenZFS by any chance? If so, that would explain a lot.
ZFS v28 is ancient and lacks many of the features found in modern OpenZFS versions. That's why the zpool version number of OpenZFS is officially v5000 to make that clear.
You could probably do quite a lot with your old v28 on a modern OpenZFS system if you stick to basic operations. If you want to use more modern features and therefore upgrade your pool, however, you will find that that is an irreversible upgrade. You can't expect a filesystem version from 2011 to work with features that were introduced seven years later. That is why we have feature flags now, so a specific ZFS dataset and implementation can list what they support or require and gracefully deal with incompatibilities. Though feature flags probably didn't exist in 2011 yet, when ZFS v28 was released.
I have been using ZFS for almost 20 years now. No, i have not upgraded the zpool, it stays on v28 which all ZFS derivatives can handle - i thought. OpenZFS can not properly handle v28 ZFS disks, as it breaks them.
I know v28 is old and does not have fancy features, but i dont care. The important thing to me is to protect my data. Old ZFS v28 does that. OpenZFS with new features does not, it destroys disks. I might as well use btrfs or ntfs if i dont care about data integrity.
OpenZFS renders ZFS disks unusable and messes up disks. And maybe data, as well. I do not trust OpenZFS.
OpenZFS messes up ZFS disks. OpenZFS cannot be trusted, as your disks are unsafe. See my post above.
The only reason to use ZFS is for its superior data protection. Not because it has fancy features. What do you prefer, a fancy filsystem that messes up your data, or a boring filsystem with 100% data protection?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
