On ZFS becoming the only available FS

News and Announcements related to GhostBSD
kraileth
Posts: 312
Joined: Sun Sep 04, 2016 12:30 pm

On ZFS becoming the only available FS

Post by kraileth »

Just read that there seem to be plans to drop UFS support in GhostBSD. If anybody feels like listening to me, by all means reconsider this!

I'm all for ZFS and have argued that I'd like to have BEs supported about a year ago. The general tone back then was: ZFS doesn't make such a good desktop FS. What exactly has lead to changing your minds?

Now that i386 is done for, dropping UFS is the next radical and in fact baneful change that makes it increasingly hard for me to recognize the GhostBSD project that I know and love. For me it was/is a nice GTK+ alternative to TrueOS. While the latter has some really, really neat things in store, it's simply at least one step ahead of what I can use right now.

Should GhostBSD decide to drop UFS support, I'm out. No, that's not a threat, it's a fact. I'm not mortally offended by such a decision; the single reason is that I'm simply stuck with a laptop that cannot boot off GPT partitioned drives and it was decided a year ago that it's not worth implementing MBR-ZFS. This is why I rely on an MBR-UFS drive for the OS and then create a zpool with various datasets by hand!

Oh, and please don't recommend new hardware. It's a third gen i7 machine with 16 GB of RAM which may not be new and shiny but should be pretty much sufficient. I'm in the middle of a long-term fight with the legal authorities of my country (I refuse to accept that they are violating my basic rights as granted by law - but the authorities don't care and probably need to be forced by going to court until the case can be escalated to the EU court). It should not be too hard to imagine that I'm short on money and will be for the foreseeable future.

So are there any reasons where dropping UFS really provides a benefit?
ASX
Posts: 988
Joined: Wed May 06, 2015 12:46 pm

Re: On ZFS becoming the only available FS

Post by ASX »

hey kraileth, :)

first, you have implied a bit too much, or may be "we" or more probably "I" have written something badly;

True I'm very tired of people trolling here, like those saying "GhostBSD eat all my 1 GB RAM", so may be some of my answer is particularly bitchy, while in reality things are usually reconsidered and discussed more properly.

True, we have plan to implement "boot environments" for recovery, as you know this is certainly desirable;
that doesn't mean UFS will be dropped completely, but at this time it is not clear what the future will be, it could be we will maintain alternate setup (UFS w/o BE and ZFS w/ BE), or ... may be not.

The fact that FreeBSD use two ZFS pools on MBR, most likely is because of MBR partition size limit (2TB, w/ 512 byte/sector disks), and a ZFS partition larger than that can't be bootable; after that, you can build a ZFS pool as large as you want.

However, considering we are targeting a Desktop usage, provided we document such limitations, I'm all for maintaining support of MBR, but we have to balance our desire with the limited manpower (actually ericbsd alone) and "we" might not be able to provide all features we would like. That's is the reality of the things as of today.

Additionally, while the primary install storage will be ZFS, nothing should prevent to manage additional partitions as UFS, and however we are ready to reconsider anything, but you all have to understand the limitations, it is simply impossible to charge ericbsd more that he currently is, simple as that.

(I'm curious anyway, what sort of issues is experiencing your i7 3rd Gen notebook, that would require MBR ?, Is that a Dell ?, cause I'm on a similar i5 3340m right now, e6330 precisely.)

Like has happened in the past, join us on IRC, there we can explaine or discuss faster.

By the way, yeah, you can read my posts as "buy new hardware", true, but it simply means buy a core 2 duo as a minimum, they are very cheap on the used market anyway and are all 64 bit enabled. Am I asking too much ?

As for "dropping", may be you know, may be you don't, so here it is, (that is from software engineering books):
The only way to speed up an IT project that is late, is to cut out non essential features, and we are late ... in some way I feel we have to do what we have to do, like it or not.
User avatar
ericbsd
Developer
Posts: 2052
Joined: Mon Nov 19, 2012 7:54 pm

Re: On ZFS becoming the only available FS

Post by ericbsd »

I am not totally sure about supporting ZFS only but dropping i386 it must be done.
ASX
Posts: 988
Joined: Wed May 06, 2015 12:46 pm

Re: On ZFS becoming the only available FS

Post by ASX »

kraileth wrote:I'm simply stuck with a laptop that cannot boot off GPT partitioned drives
I remember once you mentioned a Dell e6430 .. is that the laptop you are talking about ?
As I wrote before, I have a Dell e6330, which is more or less the same machine with a different screen size, and that boot from GPT but first the laptop display a message like "invalid partition table", despite the message, pressing the enter key lead to a successful boot.

Sub-optimal, I know. I have not tried to boot with UEFI enabled (you know we had a bug in xorriso, now fixed but not yet in repos, that prevented us to include uefi support in alpha and beta ISOs).

Please ping back, we can discuss further about that BIOS/UEFI bug. ;)
User avatar
NevilleGoddard
Developer
Posts: 517
Joined: Thu Dec 22, 2016 10:30 pm
Location: Japan

Re: On ZFS becoming the only available FS

Post by NevilleGoddard »

It seems this happens on Dells even with Windows installed

http://en.community.dell.com/support-fo ... t/19469208
kraileth
Posts: 312
Joined: Sun Sep 04, 2016 12:30 pm

Re: On ZFS becoming the only available FS

Post by kraileth »

ASX wrote:True I'm very tired of people trolling here, like those saying "GhostBSD eat all my 1 GB RAM", so may be some of my answer is particularly bitchy, while in reality things are usually reconsidered and discussed more properly.
That RAM "issue" is bullshit, of course. I also have no idea why people would like to have a pile of unused (?!) RAM instead of putting it to good use. I'm not disagreeing with you at all and I can perfectly understand that it's tiring when a lot of those posts pop up. I'm well versed in sarcasm and cynicism myself. However my point of exhaustion on that topic has simply not been met so far, so I still try to put it friendly that they are talking garbage. The time will probably come when I'm sick of it as well. :P I also think that a pluralistic community is beneficial for gbsd. If I manage to throw in a more friendly tone now and then that surely won't hurt. I'm not trying to hold sissies who cannot stand a honest reply. But I'm trying to keep up the friendly face of the gbsd community. Why? Think of first time visitors. They look at the forums and the first thread they read is one where somebody is being ridiculed. It doesn't matter if that person deserved it because he made clear in another thread that he's a genuine moron. And it also doesn't matter that people who show actual interest and do their part of the work are being treated very friendly. There's no second chance for the first impression. That's my primary motivation for trying to reply friendly even to semi-idiotic posts. Not necessarily because the poster deserves it but because I'm interested in leaving a good impression on other readers.
True, we have plan to implement "boot environments" for recovery, as you know this is certainly desirable;
that doesn't mean UFS will be dropped completely, but at this time it is not clear what the future will be, it could be we will maintain alternate setup (UFS w/o BE and ZFS w/ BE), or ... may be not.

The fact that FreeBSD use two ZFS pools on MBR, most likely is because of MBR partition size limit (2TB, w/ 512 byte/sector disks), and a ZFS partition larger than that can't be bootable; after that, you can build a ZFS pool as large as you want.

However, considering we are targeting a Desktop usage, provided we document such limitations, I'm all for maintaining support of MBR, but we have to balance our desire with the limited manpower (actually ericbsd alone) and "we" might not be able to provide all features we would like. That's is the reality of the things as of today.

Additionally, while the primary install storage will be ZFS, nothing should prevent to manage additional partitions as UFS, and however we are ready to reconsider anything, but you all have to understand the limitations, it is simply impossible to charge ericbsd more that he currently is, simple as that.
I'm not arguing against this as I'm aware of how complicated it all is. Also I do not demand that Eric (or whoever) solves my problems. I'm working on it on my own when I find the time. The trouble was just that I had come to the impression that this kind of work is not even welcome at all because UFS was going to be dropped anyway. If that's not the case - everything is fine.

The most pressing issue for me is GELI support because I want to use gbsd for my desktop and laptop at work. I've understood that the problem with this is the ancient fork of the shell based installer backend (which nobody loves much anyway). I'm trying to set aside some time each week to dig a little into Python. Right now that's on hold because I'm preparing to move houses in January and there's a lot of work to do with that. But in general I'd like to see a purely Python installer backend. So far I've played a little with py-freebsd and can get the GEOM info from the kernel in XML. I've taken a look at how XML works and need to understand how to parse it with Python next. Then I want to look into getting partition information from raw disks and detect filesystems on the partitions. The goal is writing something that could probably be called "py-diskinfo". That should be something that can be built upon for a new installer backend.
(I'm curious anyway, what sort of issues is experiencing your i7 3rd Gen notebook, that would require MBR ?, Is that a Dell ?, cause I'm on a similar i5 3340m right now, e6330 precisely.)
No, it's an ASUS K95V (the same machine that has the additional nvidia card). Whenever any of the two drives has a GPT partition, it disappears from the boot options menu in the BIOS.
Like has happened in the past, join us on IRC, there we can explaine or discuss faster.
Yeah, would love to. Let's say it's a time issue - time in the evening is a bit complicated. Perhaps it will be easier after the move (hope so).
By the way, yeah, you can read my posts as "buy new hardware", true, but it simply means buy a core 2 duo as a minimum, they are very cheap on the used market anyway and are all 64 bit enabled. Am I asking too much ?
Definitely not. The point here is that there's conflicting expectations. Gbsd is a desktop distro of FreeBSD and for most people that implies "doing actual work with it" which simply requires some decent hardware to do. LLVM 4+ is a beast of a package and so are LibreOffice, Chromium and some others. It does make very little sense to use those on old hardware for real work. But then there are tinkerers, people who want to run a desktop on i386 simply because they can. It's l'art pour l'art. I admit to have a soft spot for that. And one could also argue that supporting multiple architectures has the additional benefit of catching odd bugs before they really hit hard - bugs that would have gone unnoticed if tested on just one arch. That's the theory, though. If low on resources (which certainly is the case with gbsd) we have to make practical decisions. That's why I'm not going to speak against dropping i386 (I would still like to offer an unsupported i386 build with mainline FreeBSD package repos for one desktop, though.).
As for "dropping", may be you know, may be you don't, so here it is, (that is from software engineering books):
The only way to speed up an IT project that is late, is to cut out non essential features, and we are late ... in some way I feel we have to do what we have to do, like it or not.
In fact I admire how the OpenBSD guys do it. But that does come at a cost, hence their stance of "OpenBSD works for you? You're welcome to use it. Doesn't work for you? Too bad, use something else then". And even OpenBSD follows the strategy of "cut something on -CURRENT, wait a while if somebody screams". Dropping things is not bad at all, I fully support that (I'm not a big fan of bloat). But taking stuff away that's being actively used for good reasons is rather complicated. ;)
ASX
Posts: 988
Joined: Wed May 06, 2015 12:46 pm

Re: On ZFS becoming the only available FS

Post by ASX »

Glad to read you again kraileth :)

(I will answer you later, being to busy right now)
User avatar
ericbsd
Developer
Posts: 2052
Joined: Mon Nov 19, 2012 7:54 pm

Re: On ZFS becoming the only available FS

Post by ericbsd »

kraileth wrote:That RAM "issue" is bullshit, of course. I also have no idea why people would like to have a pile of unused (?!) RAM instead of putting it to good use. I'm not disagreeing with you at all and I can perfectly understand that it's tiring when a lot of those posts pop up. I'm well versed in sarcasm and cynicism myself. However my point of exhaustion on that topic has simply not been met so far, so I still try to put it friendly that they are talking garbage. The time will probably come when I'm sick of it as well. :P I also think that a pluralistic community is beneficial for gbsd. If I manage to throw in a more friendly tone now and then that surely won't hurt. I'm not trying to hold sissies who cannot stand a honest reply. But I'm trying to keep up the friendly face of the gbsd community. Why? Think of first time visitors. They look at the forums and the first thread they read is one where somebody is being ridiculed. It doesn't matter if that person deserved it because he made clear in another thread that he's a genuine moron. And it also doesn't matter that people who show actual interest and do their part of the work are being treated very friendly. There's no second chance for the first impression. That's my primary motivation for trying to reply friendly even to semi-idiotic posts. Not necessarily because the poster deserves it but because I'm interested in leaving a good impression on other readers.
Not sure if you know, but firefox by itself take about 8GB of ram on my most common use and i386 have limits of 3GB, yes you can have firefox running or another browser, but it is making the system sluggish.
kraileth wrote:I'm not arguing against this as I'm aware of how complicated it all is. Also I do not demand that Eric (or whoever) solves my problems. I'm working on it on my own when I find the time. The trouble was just that I had come to the impression that this kind of work is not even welcome at all because UFS was going to be dropped anyway. If that's not the case - everything is fine.
There was a conversation about maybe dropping UFS, there is no decision made and actually, UFS is probably a must-have, but the day I see no use to it I will drop it currently I run under ZFS only.
kraileth wrote:The most pressing issue for me is GELI support because I want to use gbsd for my desktop and laptop at work. I've understood that the problem with this is the ancient fork of the shell based installer backend (which nobody loves much anyway). I'm trying to set aside some time each week to dig a little into Python. Right now that's on hold because I'm preparing to move houses in January and there's a lot of work to do with that. But in general I'd like to see a purely Python installer backend. So far I've played a little with py-freebsd and can get the GEOM info from the kernel in XML. I've taken a look at how XML works and need to understand how to parse it with Python next. Then I want to look into getting partition information from raw disks and detect filesystems on the partitions. The goal is writing something that could probably be called "py-diskinfo". That should be something that can be built upon for a new installer backend.
D'ont invest time at the wrong place I work with Kris Moore and we will rewrite pc-sysinstall in GO in the future, and for now, I have invest lot of time in pc-sysinstall code to make it work my way that, I willl not drop it and most of my issue with pc-sysinstall is that I did not use it as it is intended. GELI aperanltly work for ZFS, but iXsystems is paying people to add support for ZSF encryption in FreeBSD, which will be better than GELI and it basically one of the reasons why I am looking to drop UFS.

Definitely not. The point here is that there's conflicting expectations. Gbsd is a desktop distro of FreeBSD and for most people that implies "doing actual work with it" which simply requires some decent hardware to do. LLVM 4+ is a beast of a package and so are LibreOffice, Chromium and some others. It does make very little sense to use those on old hardware for real work. But then there are tinkerers, people who want to run a desktop on i386 simply because they can. It's l'art pour l'art. I admit to have a soft spot for that. And one could also argue that supporting multiple architectures has the additional benefit of catching odd bugs before they really hit hard - bugs that would have gone unnoticed if tested on just one arch. That's the theory, though. If low on resources (which certainly is the case with gbsd) we have to make practical decisions. That's why I'm not going to speak against dropping i386 (I would still like to offer an unsupported i386 build with mainline FreeBSD package repos for one desktop, though.).
TrueOS is a desktop and server distro of FreeBSD too and I don't see conflicting expectations. Sure TrueOS is becoming more like fork than a distro, but still that right now they are a distro. GhostBSD is changing and FreeBSD won't change. TrueOS right now is the most popular BSD on distro watch, because they took a risk that did not want to take and not that I work with them I see what they are trying to accomplish, to a point that it will be more than an advantage to use TrueOS make the BSD of GhostBSD than FreeBSD itself iXsystems have hired Kernel developers and they are adding functionality to FreeBSD for FreeNAS/TrueNAS but at one point me and Joe want to see TrueOS Core be the replacement of FreeBSD for GhostBSD and FreeNAS/TrueNAS.

For your info, ASX was against abandoning i386 until he realizes it is a dead weight and a problem for the project. Another thing is that tinkerers can go and install FreeBSD and make what they want with it. Yes me working for iXsystems will have a direct impact on GhostBSD, but GhostBSD will still remain independent of iXsystems unless I something happens that I can't refuse. I will admit that I was afraid of dropping i386, but it is done and we are not going back to i386.


OK, now if you have any problem with the drop of i386 GhostBSD can be forked and anyone can do what they want with the code. I won't hear anything about i386 it is the pass and dead for this project dot at the line. Anyone that has a problem with the decision that me ASX take I have one thing to say; be involved in #ghostbsd-dev IRC channel.


Also, I am looking to support arm64 in the future and the drop of i386 can only make sense.
ASX
Posts: 988
Joined: Wed May 06, 2015 12:46 pm

Re: On ZFS becoming the only available FS

Post by ASX »

kraileth wrote:I also think that a pluralistic community is beneficial for gbsd. If I manage to throw in a more friendly tone now and then that surely won't hurt.
Agree, of course.
I'm not trying to hold sissies who cannot stand a honest reply. But I'm trying to keep up the friendly face of the gbsd community. Why? Think of first time visitors.
Good point! Now please, tell me: when you, as a first time visitor to some forum, start to complain about some aspect of the project ? and even worse with unsubstatiated arguments ?
Probably never ... I already know that.

That's is what that guy did, and that's why he got that type of unfriendly answer.

The same more or less happened to another guy, time ago, who started to complain about "security support" in GhostBSD, that after trolling here started to troll on irc too, and later on freebsd forum. :lol:
There's no second chance for the first impression. That's my primary motivation for trying to reply friendly even to semi-idiotic posts. Not necessarily because the poster deserves it but because I'm interested in leaving a good impression on other readers.
Well, you have more patience than me, mine sometimes is simply exhausted. ;)

About UFS vs. ZFS, Eric already answered something, I can only add that ZFS is the future and UFS is showing its age, UFS has been great, but now it is time to move on.
UFS supposrt is there for the upcoming 11.1 release, that will leave enough time to discuss further about the future.
time in the evening is a bit complicated.
Fine, each one of us has its own committments and we can only dedicate part of our free time to the project; since when we implemented our own repos things became more complicated for us, even building the ISOs require that we verify the freebsd ports, our own ports, (eventually upgrade the build environment up to the latest patch level), build the packages, transfer the package repos to the pkg server and finally build the test ISOs;

before it was simply a matter of start the ISO build (and use the FreeBSD repos).

That, and the fact that currently no dev is running on i386 and that no much users provide feedback on i386 builds, along with the increased difficult to run up to date software which is increasingly bloated led us to decide for dropping i386.

There are alternatives, like FreeBSD itself, and other like OpenBSD or even Linux that can provide better support for i386 arch, we simply are a too small team to do that.
No, it's an ASUS K95V (the same machine that has the additional nvidia card). Whenever any of the two drives has a GPT partition, it disappears from the boot options menu in the BIOS.
It may not be the answer you like, but when I find myself in trouble with some hardware, I simp'ly sell out that hardware and buy a different one. (it is the least problematic path, in my opinion ...).
The point here is that there's conflicting expectations. Gbsd is a desktop distro of FreeBSD and for most people that implies "doing actual work with it" which simply requires some decent hardware to do. LLVM 4+ is a beast of a package and so are LibreOffice, Chromium and some others. It does make very little sense to use those on old hardware for real work.
I'm surprised here ... the old hardware doesn't include i386 arch ?
But taking stuff away that's being actively used for good reasons is rather complicated.
Now, speaking of UFS vs ZFS ... what provide UFS that is not available in ZFS ?
You know that I tried to use UFS on the (pkg) builders, where we tried to use a big "ccache" (70~100 GB), basically constitued of small files (24 Kbyte on average, and thousand of files per directory).

I spent lot and lot of time building and rebuilding, changing parameters (of UFS and of ccache) to try to improve ccache performance and the fact was that UFS was a bottleneck. Yes, it is an extreme use case, I know that, but the fact remain. In all other cases ZFS is able to provide better reliability, same or improved performance.

Lately I did the same using ZFS and I would say that (after long testing time and tweaking) it is also able to provide great performance for "lot of small files" use case.

The other "often advertised" requirement bound to ZFS is the RAM usage, but in reality 4 GB RAM are just fine, more is better of course, but 2 GB also works without issues. The only ZFS feature that require ton of RAM is deduplication, something that however is not available on UFS.

Additionally, FreeBSD 11.1 added support for compressed ARC pages (ZFS cache pages) which it means it require less RAM than before to cache the same amount of info, or that can cache more amount of info into the same ARC used RAM. (of course that come with some light CPU usage price).

But, like I said lot of times already, ZFS main feature is about "easy management"; storage management is the keyword.

Let me clarify with a simple but real example:

we have a "pkg builder" machine that will build 27000 packages and will prepare a small filesystem tree that include some metadata; when the build is complete we need to transfer that filesystem tree onto our "pkg server";
of course, we have a web server running and serving those packages, so how do we transfer that packages ?
With ZFS, and specifically "zfs snap ...; zfs send .... ! ssh pkg-server zfs receive ..." we can do that reliably and with very few commands, without worrying about traffic interruptions and other issues: either the complete transfer will succeed or not, and that will assure our pkg-server is always consistent.

Doing that using UFS is not so simple ... and I will leave that as an exercise to any UFS fan. ;)
User avatar
ericbsd
Developer
Posts: 2052
Joined: Mon Nov 19, 2012 7:54 pm

Re: On ZFS becoming the only available FS

Post by ericbsd »

I will also add about ZFS that it runs well under MBR, but MBR is just not made for a lot of storage capacity. Since ZFS MBR installation is now possible under pc-sysinstall, I might add back the capability to the installer. Soon the use of UFS will be less critical for GhostBSD and not only that now I understand how ZFS work I will be able to do a partition editor for ZFS which means the use of UFS will practically not attractive anymore.

I also plan to integrate live preserver to GhostBSD, and it is ZFS only. ZFS can be tuned to a point to work better and faster than UFS. The ability to do a snapshot before updating and have the capability to boot that snapshot if anything goes wrong after the update in today ages it is a must-have feature.

I can go On, but I must work.
Post Reply