ZFS FreeBSD moving to ZFS-on-Linux

I know I'm only one person, but I use FreeBSD for a number of reasons, and ZFS has never been one of those reasons. I know that there are others who feel the same way about it. Hopefully all of the people who came to FreeBSD just because they wanted ZFS will have had time by now to catch on to all the other reasons for using FreeBSD.
Nice to read your post.
I use bsd because it is stable, networking and packages are awesome, and it is clean.

It is a good thing that ZFS goes further.
 
Key ZFS developers from the FreeBSD are happy to support this move. The project (soon to be formerly) called ZFS on Linux will be taking on board automated FreeBSD tests so that changes made by Linux devs don't break ZFS for FreeBSD and vice versa - I believe this isn't something the original OpenZFS project ever offered.
This information is, I understand, available via the OpenZFS Leadership meeting videos - though I tend to get a condensed version via Allan Jude on the BSDNow podcast.

Checking out the OpenZFS on Mac forums, there are a couple of threads (here and here) that say that the Mac port was originally based off of ZoL and so switching back should not be too hard. So, potentially if ZoL are open to having FreeBSD automated tests so things work across the two systems, they would likely be open to having Mac tests too.

Lookout for Dragonflies ;)

I don’t know much about Behlendorf. The little I saw of his communication was always positive and constructive. He might be one of the great developers who picked up the wrong OS.

There was a long period when if I ran out of the funny videos on youtube, and I still felt a bit sad, I started reading the btrfs-dev mailing list and got high in ten minutes or less. It also told me everything about the general Linux development. Ten years ago it was already clear to any sane person who has developed software in any language, and worked with other people, that btrfs never would be stable. Half of the emails on the list were "I’ve been using it for two long months, and I still have my data. It is amazing! Just don’t go into corner case!". The other half was like "I can’t mount my pool anymore. This was the backup of the other pool. Can you please help?" At the same time, at least to big commercial distributors put it on their so-called stable install CD. I think one of them made it default for one release.

On the other hand, the ZoL might be better. A developer who picks up a project like ZFS is more likely a reasonable person than someone who develops the devnullFS for ten years. There is a reflection between the developer and the project in both ways. If that’s the price to have encryption, let’s go for it. Even if I used GELI on production servers for years. It worked like a charm. The sole reason I stopped using it was that I switched to a provider who offers native encryption on the disk layer already. I was just wondering why this thread looked like if we were already behind when it performs better. Although the performance was never the first or the second most important detail about ZFS, neither was it the last one.

It’s the explanation of why the name should be ZoL I can’t stop laughing about. It reminds me of the audition of Mark Zuckerberg by Congress.

"If you would want it, do you have access to the confidential data of your users? Could you read it?"
"That would be a serious security breach. We have decent security to prevent such things."
"Don’t talk to me as if I were stupid. I asked you that if you wanted, could you access that data?"
"Congresswoman! Why would we ever, under any circumstances, in any dimension of the whole multi-universe even think about such thing?"

I don’t know how it is different from renaming it to MicrosoftFS or maybe YourFilesRentedFromOracleFS.
 
I know I'm only one person, but I use FreeBSD for a number of reasons, and ZFS has never been one of those reasons. I know that there are others who feel the same way about it. Hopefully all of the people who came to FreeBSD just because they wanted ZFS will have had time by now to catch on to all the other reasons for using FreeBSD.

I’m one of those who came to FreeBSD solely for the ZFS.

Later, when I realized we had both /etc and /usr/local/etc, and why, I already knew it would hurt even thinking about going back. Although my gateway drug wasn’t that bad. It was Gentoo.
 
I'm not currently using ZFS, but let me just say I hope FreeBSD can stave off the Linux pollution it seems to be fighting all the time.
 
Later, when I realized we had both /etc and /usr/local/etc, and why, I already knew it would hurt even thinking about going back

Well, this is a possible viewpoint. But there is more to it. There is only a single number, the code revision, and that number fully and sufficiently defines the running system. And that is also not a value in itself, it's a prerequsite, to be able to look at the bits and bytes. Because, for that to begin with, you need a defined state. Without a defined state, there is no means of logical verification.

What worries me more is that nobody does logical verification, and not so many people look at the bits and bytes at all. When I start to look at the bits and bytes -and I do so if somthing annoys me the way it works, and I for my personal taste want it different-, if I look close enough, I happen to find logical flaws.
But this is not what this discussion is about. This discussion is about tastes and imagos. It is about politics - far away from the bits and bytes.

Seems to me we got decadent, and that does not concern Linux, it concerns all of the stuff. And I see three reasons:
  • it is no longer necessary to strive hard to get even some basic functionality operative. Systems tend to work out of the box.
  • The whole system has become just too big for anybody to get a deep understanding of more than only a small fraction of it.
  • Everybody is now using computers, and it is not necessary to have much of an idea how the thing works. I'm not sure if that's a good thing. I don't think kiddies need computers in elementary school, and I still feel a campfire in the wilderness a lot more soothing.
Meanwhile we are sitting on a pile of stuff that might just work more or less by accident.
So, please, do me a favour: if you want to bash something, do it with good arguments.
 
What worries me more is that nobody does logical verification, and not so many people look at the bits and bytes at all. When I start to look at the bits and bytes -and I do so if somthing annoys me the way it works, and I for my personal taste want it different-, if I look close enough, I happen to find logical flaws.
On this planet, the above seems to cover most areas of life.
Seems to me we got decadent, and that does not concern Linux, it concerns all of the stuff. And I see three reasons:
  • it is no longer necessary to strive hard to get even some basic functionality operative. Systems tend to work out of the box.
  • The whole system has become just too big for anybody to get a deep understanding of more than only a small fraction of it.
  • Everybody is now using computers, and it is not necessary to have much of an idea how the thing works. I'm not sure if that's a good thing. I don't think kiddies need computers in elementary school, and I still feel a campfire in the wilderness a lot more soothing.

Today, something happened to me. During the years I used Linux, it happened to me many times. Many nights, it made me sit in the car, and visit the server room, far away from the city to get a console. Until today, it had never happened to me under FreeBSD, even though I have way more FreeBSD servers running than how many Linux boxes I could ever touch, and I have been using it for more than ten years.

After I ran freebsd-upgrade, I could’t login via SSH. I did it the canonical way. I didn’t save myself or the server from any reboot I was told to do. I upgraded the packages between the second and third round of freebsd-update install. I can’t see how it could have been my fault. Fortunately, it was a test server, and I had remote console, but in the past, I felt much safer doing the upgrade. It was the upgrade from 11.2 to 12.0. I tested it inside a VM first. (That’s also new. I used to be bolder with FreeBSD). Then, I tested it on a production server hosted somewhere else.

Then I did it on Google Compute Engine, and I couldn’t login any of the two servers.

Someone (not me but who created the install image on GCE many years ago) managed to put a few lines at the end of the sshd_config. One of the lines was a Chiper setting. I don’t remember seeing any warning about it anywhere. (I mean, logs, login screen, whatever). FreeBSD 12 said, "I don’t like this Chiper, goodbye".

I still have servers at places where I have either no remote console access, or it takes ages to get one. They are in other countries.

People commit mistakes. Or one could say this was not a mistake from the maintainer. I don’t know. But if I were to prepare an upgrade for an operating system, I would think, right after the kernel and the shell, the ssh daemon is the third most important thing that should work, no matter what (unless the user did something crazy).

Since I have no Chipher line in the sshd_config anywhere else, even doing a few test upgrades elsewhere did not help me expect this.

The sad part is that the sole reason I had two additional servers in GCE today is that I spent five hours of my life on the google-cloud-engine daemons that have hardcoded paths from Linux, refer to non-existent files, don’t process the config templates they are supposed to process, don’t have such a basic error handling that if an executable is missing, the log should display the name of the executable (which was also from Linux), and I could go on. Another daemon of this package adds two lines to my /etc/hosts file in every few minutes. Over time, my hosts files grow to a few megabytes size. In the end, I wrote a script to re-create the hosts files on my servers from templates because I had no mood to trim them by hand on fifteen servers again and again.

For the latter, I don’t blame anyone related to FreeBSD, because these scripts are written in Python and I believe they are from Google, and it fits well with the rest the company did in the last one or two years.

On the other hand, I can’t blame either Google for adding a Chiper line to the sshd_config (or the person from FreeBSD if they did it). I think there should be an automated test in the upgrade process that tells the user, "Hello. I am the SSH Daemon. I have a bad news for you", during the upgrade, before the reboot happens. They wouldn’t have to think about every possible line that became unsupported. It would be enough to make the sshd daemon check the config file whether it is valid or not.

It was also this year when I had some shared library error messages in a jail after some upgrade. Maybe it was me. I’m not sure. But I have been upgrading that server for maybe eight years. It’s one of my first FreeBSD machines co-located.

The answer is simple. The technical evolution has become magnitudes faster than the human evolution. A few decades ago, one could understand maybe every type of computer they had around in near to 100%. Today, understanding certain config files may be a full-time job.
 
  • Thanks
Reactions: PMc
Far be it from me to rant, but I would think twice before going on ZoL-rebased ZoB given 1) how big of a Systemd-grade mess, ZoL has become and 2) Debian's questioning of their faith in Systemd ( See here)
 
What does ZoL have to do with systemd? While there are some thin linkages (like how to mount and scrub ZFS from systemd startup scripts), ZoL seems to be perfectly happy to run on other init systems.

And if you talk to Linux file system developers, you'll find that your mistrust of systemd is widely shared, so I'm not worried about ZoL becoming dependent on systemd.
 
I'm not saying that ZoL and Systemd are interwoven.

I am just saying that ZoL is growing to be as bloated, as inefficient and as chaotic as Systemd.

I am also saying that, at some point, the users and the devs will become skeptical to the point of reconsidering the whole project and will reverse course leaving Freebsd users hanging high and dry.
 
It is not a secret zfs is one complex piece of code.
But then I use ufs with journaling & soft-updates and fsck solves any problem.
I don't even need ufs snapshots nor background-fsck.
My 5-cent, if your computer has at least 10 drives, zfs is a good choice.
 
What evidence do you need?

Other than the recent SIMD debacle (fallout from license wars), and as a user of ZFS on both platforms, I haven't experienced any inefficiencies or bloat.

So what we are asking you for is to point out what you have seen to raise your concerns, and (even better) where you have raised these concerns with the project.
 
After power outage I have had meta data corruption in freebsd-zfs and it could not be solved in any way possible.
As there is no fsck and you run into a never fixed (maybe opensolaris) bug ...
PS : I don't know about the current and newer linux-zfs code-base they are using. But it has a large user-base.
 
I am not questioning pre-rebasing ZoB.

I am questioning the bazaar that has become of ZoL.

Why don't you ask Theo de Raadt if he would implement ZoL as is in OpenBSD?

Alternatively, why don't you ask the learned folks at Google, AWS or Microsoft if they would use ZoL as is for their infrastructure?

The main argument of this rebasing is cross-platform compatibility.

I disagree with that argument because Freebsd and Linux are rarely used concurrently in a same organization for same application.

I think it that it would have been more BSD-ish to streamline and optimize ZoL even at the cost of losing some marginal features (used less than 10% of the time)

Last word, I didn't use ZFS at my last job because we customized/coded our own OS/FS.

Just my two cents for the new year.
 
I'm not saying that ZoL and Systemd are interwoven.

I am just saying that ZoL is growing to be as bloated, as inefficient and as chaotic as Systemd.

I am also saying that, at some point, the users and the devs will become skeptical to the point of reconsidering the whole project and will reverse course leaving Freebsd users hanging high and dry.
I had the same thoughts recently while reading about the deliberate use of "embrace, extend, extinguish" strategy being used for taking control of the entire Linux ecosystem, especially by absorbing basic unix utilities (both server and desktop utilities such as dns, consolekit, and mounting home dirs), then extending those utilities within systemd (e.g. elogind has 5 times more lines of code than consolekit because "features"), and finally extinguishing the proven, legacy utility (e.g. "modern" desktops may no longer run with consolekit).

The extinguished software is dismissed as "unsupported" and "has had no maintenance in x years". Because the embrace/extend/extinguish team started out by helping with maintenance, moving the source code into their own repo, then extended and renamed the utility, then declared the separate utility dead and their own frankencode to be the only True One.

I see that easily happening also with zfs (I HOPE not!). The zfs compatibility matrix may be an early warning sign -- I count 13 "features" that are in Linux's ZFS but not in FreeBSD's zfs. So we've already had the "embrace", now we're getting the "extend"....

and then extinguish. [Extinguish doesn't mean that zfs will be gone, only that the True ZFS that systemd and other stuff requires is only available from one team and only works with that team's Stuff.]

I trust that the developers of ZOL are ethical folk and work with non-linux developers with whole-hearted cooperation.
 
I trust that the developers of ZOL are ethical folk and work with non-linux developers with whole-hearted cooperation.

Your faith in humanity is admirable. I hope you aren't disappointed.
 
I trust that the developers of ZOL are ethical folk and work with non-linux developers with whole-hearted cooperation.

There are several linux distros such as devuan, slackware, gentoo, apline linux, etc. that don't use systemd so ZOL developers will have to keep this in mind.
 
Your faith in humanity is admirable. I hope you aren't disappointed.

Yeah. Meanwhile I'm backing off from using Gentoo on zfs and switching all of my systems back to FreeBSD with zfs from base. I had found that I could create a zpool in FreeBSD and successfully import that pool into Gentoo but I fear that in the future it may become more problematic, rather than more reliable, to move pools between FreeBSD and Linux (my faith in Linux developers is weak).
 
Yeah. Meanwhile I'm backing off from using Gentoo on zfs and switching all of my systems back to FreeBSD with zfs from base. I had found that I could create a zpool in FreeBSD and successfully import that pool into Gentoo but I fear that in the future it may become more problematic, rather than more reliable, to move pools between FreeBSD and Linux (my faith in Linux developers is weak).
It's an interesting question. Can you create a zpool without new features so it is compatible between linux and bsd ?
 
I hope when ZoL become the default ZFS, upgrade of earlier installation will be possible without risk or need of manual conversion of file system, etc.
 
Back
Top