Linus Torvalds Doesn't Recommend Using ZFS On Linux

[ryao]

Disagree.

Obviously patents are how they'd attack the GPL code, but I think it's very clear that would be a tougher argument to make than the straightforward copyright claim they'd have with the ZFS code.

In the end, it's just a matter of degree though. I agree they absolutely could drag the gpl code into court if they wanted to.

They don’t have a copyright infringement claim to make according to attorneys.

https://www.softwarefreedom.org/reso...rnel-cddl.html

The only potential issue according to that would be all of the Linux copyright holders forming a consensus “to prefer the literal meaning to the equity of the license”.

[gilboa]

Ignoring for a second the obvious issues with CDDL vs. GPL and Oracle's horrible litigious nature (both of which makes ZOL {ZFS on Linux} legally banned in any real enterprise environment, unless that is, you are using an Oracle licensed OS), one must wonder if any of the many pro-ZOL users, really attempted to deploy it in a real, honest to God, large scale production environment (E.g. GlusterFS cluster over ZFS).

Anyone? Cause at least in my experience, unlike ext4/EXFS, when ZOL breaks (and I've seen it break badly in production environment, including very recently) you get to keep all the pieces.

- Gilboa

[k1e0x]

Ignoring for a second the obvious issues with CDDL vs. GPL and Oracle's horrible litigious nature (both of which makes ZOL {ZFS on Linux} legally banned in any real enterprise environment, unless that is, you are using an Oracle licensed OS), one must wonder if any of the many pro-ZOL users, really attempted to deploy it in a real, honest to God, large scale production environment (E.g. GlusterFS cluster over ZFS).

Anyone? Cause at least in my experience, unlike ext4/EXFS, when ZOL breaks (and I've seen it break badly in production environment, including very recently) you get to keep all the pieces.

- Gilboa

I can assure you ZoL *IS* used in enterprise. I've used ZFS in enterprise since ~2006 on Solaris, FreeBSD and Linux. It is pretty much the fix for ransomware.

The CDDL nor the GPL have restrictions on usage, only on distribution. You can and always have been able to do whatever you want on your own systems.

I posted this before. 100 PB - ZoL Implementation. Storage of that size actually isn't that unique for ZFS (typically more Solaris and FreeBSD but ZoL is getting more popular.) Most enterprises don't share information on their storage platforms. Since that one is a quite impressive research system they do have details posted about it.
https://medium.com/codedotgov/oss-sp...x-6596fca6e5f6

"unlike ext4/EXFS, when ZOL breaks (and I've seen it break badly in production environment, including very recently) you get to keep all the pieces." -- seriously? You're going to make the claim ext4 is *better* at data integrity than ZFS? No.. It's not. Not in any universe. Like Linus you don't seem familiar with ZFS.. that is ok.. but unlike Linus you shouldn't go making claims when you don't have the basic facts.

FYI, ZFS is a copy on write, always consistent file system with a checksum on every data block.
EXT4 is... not. It is a journaled, extent based file system that updates blocks in place making it not always consistent. Do you like fsck? Or data blocks with silent corrupt files? EXT4 is for when you want a small but present possibility of your pictures looking like this and never knowing till you open it.

[Dedobot]

Booting the OS from desired snapshots is neat.
Definitely very useful for desktops and mobile devices. I have no idea if this can be implemented w/o zfs code in the kernel ?
Zfs boot environments works wonderful in Solaris, i know FreeBSD have that option too ,

[k1e0x]

Booting the OS from desired snapshots is neat.
Definitely very useful for desktops and mobile devices. I have no idea if this can be implemented w/o zfs code in the kernel ?
Zfs boot environments works wonderful in Solaris, i know FreeBSD have that option too ,

Boot environments are supported on ZoL. (I think macOS too) The upper stack stuff lacks implementations such as with apt or user level tools but ZoL and grub can do this if you set the BE manually. Pretty sure Ubuntu is working on this..

...and it is neat.

[droidhacker]

I've tried ZFS for shits and giggles, and it completely obliterated my data, then started insulting me with the vocabulary of a 3rd grader. To hell with that.

[oiaohm]

The CDDL still has the terms allowing Sun (now Oracle) to publish a new version, and for anyone to then choose to use that version.

That allowing Sun does not allow Oracle. There should have been a CDDL 1.1 when Oracle acquired Sun transferring license steward to Oracle.

https://sec.report/CIK/0000709519/3

Sun ceased as a legal usable in 2010. Big problem here is legally Oracle is not the license steward of CDDL but a dead non functional company is.

[oiaohm]

URL="https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf"]https://web.mit.edu/Saltzer/www/publ...d/endtoend.pdf[/URL].

Now I get the rabbit hole of you have screwed up.

XFS has checksums also, but only on metadata. They cite it's too slow to do it on data blocks. (A problem ZFS's "terrible" design allowed them to solve.. if only XFS's design was as bad as ZFS's they could have data block checksums. )

Are you right in a XFS deployment the answer is only maybe.

The Linux system is a sandwich. Block layer-File System-Integrity Measurement Architecture(IMA)

If the IMA side is checksum the data blocks does it make any sense for the file system to duplicate? The XFS lead developer at a Linux Conf Au a few years back answered this exactly question this way why no data block checksums in the XFS file system design, This is why when you were saying the loopback stuff XFS developer was doing seam stupid its not something else is at play.

Once you consider if you are allowing the block layer to be visible though the file system the IMA on top of the file system can do per data block check sums in a file system neutral way.

Standard min requirement for IMA stuff is the file system supports extended attributes but it would be possible to make IMA work without this. So you can have end to end integrity and not give a crap about the file system.

Next is from file system to block layer. File system has not been able to tell block layer useful stuff like all these blocks own together and should be put on storage item because having half of them would as useless as having none of them.

Horrible question both of you. With ZFS can you in fact maintain your integrity insurance of the file system the data has been moved to is not ZFS. This is something the IMA path offers this is one thing that makes ZFS a terrible long term design.

What ZFS happens to be is the Block, Filesystem and IMA glued into one. You guys are being too tunneled visioned to see that XFS developer is working on making something equal but done in a different way that the end to end protection does not depend on what file system or under laying block layers you are using.

PS something else to remember iomap library is only just starting to be deployed out in the Linux kernel. There were a lot things the Linux kernel block layer could not do. There was a lot information that the file systems could not tell the block layer and a lot of information that the IMA of Linux could not access that is going to change.

The old block layer systems in Linux API/ABI are going to get deprecated so file systems will not be able to use them some point into the future.

Linux kernel is on a very interesting route and that route is going to make ZFS life harder supporting Linux and also make ZFS features less important.

[k1e0x]

Now I get the rabbit hole of you have screwed up.



Are you right in a XFS deployment the answer is only maybe.

The Linux system is a sandwich. Block layer-File System-Integrity Measurement Architecture(IMA)

If the IMA side is checksum the data blocks does it make any sense for the file system to duplicate? The XFS lead developer at a Linux Conf Au a few years back answered this exactly question this way why no data block checksums in the XFS file system design, This is why when you were saying the loopback stuff XFS developer was doing seam stupid its not something else is at play.

Once you consider if you are allowing the block layer to be visible though the file system the IMA on top of the file system can do per data block check sums in a file system neutral way.

Standard min requirement for IMA stuff is the file system supports extended attributes but it would be possible to make IMA work without this. So you can have end to end integrity and not give a crap about the file system.

Next is from file system to block layer. File system has not been able to tell block layer useful stuff like all these blocks own together and should be put on storage item because having half of them would as useless as having none of them.

Horrible question both of you. With ZFS can you in fact maintain your integrity insurance of the file system the data has been moved to is not ZFS. This is something the IMA path offers this is one thing that makes ZFS a terrible long term design.

What ZFS happens to be is the Block, Filesystem and IMA glued into one. You guys are being too tunneled visioned to see that XFS developer is working on making something equal but done in a different way that the end to end protection does not depend on what file system or under laying block layers you are using.

PS something else to remember iomap library is only just starting to be deployed out in the Linux kernel. There were a lot things the Linux kernel block layer could not do. There was a lot information that the file systems could not tell the block layer and a lot of information that the IMA of Linux could not access that is going to change.

The old block layer systems in Linux API/ABI are going to get deprecated so file systems will not be able to use them some point into the future.

Linux kernel is on a very interesting route and that route is going to make ZFS life harder supporting Linux and also make ZFS features less important.

So.. what you're saying you want to do here..... is instead of designing a new proper architecture that fits your needs, you want to bolt on a system designed for something completely different (secure boot) and place calculated checksum into xattr records? I believe the kernel also needs a list on this to know what files have checksums on them. What could go wrong? (probably a great deal, I have no idea) Funny ironic side note, ZFS checksums the xattr record too. heh (this is file based, not block based.. they actually can be used together.. if you want..) Block based however lets you do this for example as SAN storage.

I've never seen anyone use this before, maybe android does, it's not default on anything I know of and they don't do it on entire file systems for sure. But.. hey.. don't let me stop your dreams and duct tape fantasies.

Or you could just use a well trusted long standing technology designed for just that... naah... We say NIH to things like that here in Linux and fix everything with sed and python instead.

[oiaohm]

is instead of designing a new proper architecture that fits your needs, you want to bolt on a system designed for something completely different (secure boot) and place calculated checksum into xattr records?

Funny you arguement here. This is not bolting on this is using something that in the old design that is meant to be used that way. In fact something you admit latter ZFS is doing.

I believe the kernel also needs a list on this to know what files have checksums on them. What could go wrong? (probably a great deal, I have no idea)

IMA was the example he used. But he also said it did not have to be IMA. Really there is no reason why a file system cannot a flag in it superblock to say I have X feature so VFS layer added feature need to be enabled. It is possible to say all files in this file system have checksums in xattr.

ZFS checksums the xattr record too. heh (this is file based, not block based.. they actually can be used together.. if you want..)

See ZFS is placing check-sum is xattr for whole file. This does not have to be implement in the ZFS file system. If you implemented where the IMA/fsverify are this could be taken out of ZFS and implement for all file systems that support xattr to have whole file checksumming. Lets really stop design checksum per file system on per file system based system it only created increases validation work and at times unrequired extra processing.

Notice something I enable IMA on ZFS by the current design of ZFS this can be calculating the same checksum twice and consuming twice the number of bytes in the xattr with no real advantage. Basically whole file checksumming need to get out of file systems and moved to the layer above. This is Linux coming into alignment with old IRIX ways.

Block based however lets you do this for example as SAN storage.

Block level check sums can be stored in the block layer. Don't have to be stored in the file system. Rework of iomap in Linux is about changing things so checksums on blocks going to storage can be calculated and signed by the VFS/IMA level independent of file systems and in fact be more complete end to end. This is Linux coming into alignment with old IRIX ways again.

I've never seen anyone use this before, maybe android does, it's not default on anything I know of and they don't do it on entire file systems for sure.

That the problem you are too young. You have not consider that most of what you are doing with ZFS was done over a decades before. Problem when XFS was ported to Linux the other bits around it did not come with it being the XVM(logical volume manager) or the differences in VFS bit above XFS for whole file checksumming did not come either. So the XFS we have been looking at is the feature crippled version. Fully implemented version of XFS is a lot stronger competitor and it also moves a lot of other file systems up as competitive on data protection.

Or you could just use a well trusted long standing technology designed for just that.:

So you are working on the younger tech with ZFS and don't get it. In fact the way ZFS does whole files checksums comes from the historic way XFS did it. Technology wise ZFS is the child of XFS in a lot of the file protection stuff. XFS on IRIX checksums on files were done in the layer above the file system in the VFS layer with IMA is. So having full file checksum in the layer above is a long standing technology design choice for whole file check sums.

Lets say in 10 years time someone implements ZFS without checksum then some other file system comes along claims a whole stack of advantages over ZFS because it has checksums are they not idiots. This is exactly the mistake you have made with XFS totally missing how far ahead it was. The old design has some very interesting points it about time you stop claiming bolting stuff on XFS developer currently is just implementing the stuff that should have been implemented to fully port XFS originally.


The original model around XFS is design to be bolt together to reduce down the duplication of effort. So every file system does not have to write a block layer or a validation layer stuff.