Call for Foundation-supported Project Ideas

If your main use case is the desktop or embedded, UFS is perfectly fine. If it's enterprise storage; ZFS is second to none obviously.
ZFS is bloated
You cannot remove UFS2, because lower-end systems need that. XFS and ZFS are heavy on CPU and RAM, respectively. Unless they want to cut off all old laptops, and other lower-end use case scenarios, they have to keep UFS2 in the kernel. Otherwise, they need to change the slogan to, "The Power to Serve 8GB+".

ZFS is going to remain in the kernel too. Some say HAMMER2 could be a better option. However, it really does not matter, which one is the better one. They will not remove ZFS from the kernel. ZFS is the FreeBSD main selling point -- beside the BSD licence, of course.

Therefore, introducing another FS to the kernel means addition, not replacement, i.e. three filesystems, side-by-side, in the kernel. UFS2, ZFS, and XFS for example. This will not happen either. Either you need many new kernel developers to implement, test and debug it -- for a very long period, or you have to hire developers. I do not bet on the former, and the latter needs money, which according to the latest fundraising it is an impossibility. And even if that happens, then you have larger kernel, more bugs .... To conclude, for better or worse, I am sure that both UFS2 and ZFS will remain the default filesystem in the kernel, for a long time.

[EDIT]
P.S. I'm not a ZFS user, I don't like it, and I'm not defending ZFS. However, the FreeBSD Project policy on keeping and promoting ZFS is understandable.
 
You cannot remove UFS2, because lower-end systems need that. XFS and ZFS are heavy on CPU and RAM, respectively. Unless they want to cut off all old laptops, and other lower-end use case scenarios, they have to keep UFS2 in the kernel. Otherwise, they need to change the slogan to, "The Power to Serve 8GB+".

Uhh, you do realize that IRIX, the OS that XFS originates from, operates on as little as 16M of RAM? XFS came about in IRIX version 6.1, and you can run it easily. These are slow, R3000/4000 class CPUs (think the Nintendo 64 or Dreamcast if you're nooby here, or like 386/486)

Also FreeBSD has basically stopped being ran on 386-class hardware, I'm not even sure if it will compile and run on anything less than i486?

I'm not sure what your logic is that XFS is heavy on CPU. It is a standard journaling FS, and UFS is that plus soft-updates in default config. You can configure it for synchronous mode but that rarely reduces CPU/memory usage.

ZFS is going to remain in the kernel too. Some say HAMMER2 could be a better option. However, it really does not matter, which one is the better one. They will not remove ZFS from the kernel. ZFS is the FreeBSD main selling point -- beside the BSD licence, of course.

HAMMER2 is well designed, but likely non-portable to non-x86 systems.

ZFS on the BSDs doesn't bother me, nor did I offer XFS as a replacement for ZFS. For UFS, maybe. And it won't likely replace it -- I'm being idealistic.

Therefore, introducing another FS to the kernel means addition, not replacement, i.e. three filesystems, side-by-side, in the kernel. UFS2, ZFS, and XFS for example. This will not happen either. Either you need many new kernel developers to implement, test and debug it -- for a very long period, or you have to hire developers. I do not bet on the former, and the latter needs money, which according to the latest fundraising it is an impossibility. And even if that happens, then you have larger kernel, more bugs .... To conclude, for better or worse, I am sure that both UFS2 and ZFS will remain the default filesystem in the kernel, for a long time.

XFS could be implemented by a team of 3-5 people in a year or less likely if they utilized existing docs. I would be able to help, but I have three issues:

1. I've looked at a CRAPLOAD of GPL XFS and proprietary XFS code in the course of the last 5 years, so it's possible I could screw something up if I was a lead for such a project, not that I believe I have the skills to do so. We would need an auditor or someone checking up on us.
2. Full time worker in a non-tech field. I'm also a volunteer dev for other OSes than FreeBSD.
3. I am not interested in directly working with the FreeBSD devs, so I would have to leave that to someone else.

And let me remind you, I'm not demanding we put effort here to do this. Grahamperrin requested I migrate my discussion here after I mentioned it in the foundation soliciting development input and ideas. Overall, I'm not pleased with the recent changes the FreeBSD project has made, so I'm likely jumping ship and was just musing a wishlist.
 
I think you're underestimating how long it takes to properly develop and stabilize a file system. File systems aren't whimsical toys. It took nearly a decade for ZFS obtain it's stability; APFS four years given Apple-like engineering resources.

Here's a better idea; study the UFS/GEOM code, and experiment with improvements yourself.
 
I think you're underestimating how long it takes to properly develop and stabilize a file system. File systems aren't whimsical toys. It took nearly a decade for ZFS obtain it's stability; APFS four years given Apple-like engineering resources.

Here's a better idea; study the UFS/GEOM code, and experiment with improvements yourself.

That assumes writing one from scratch. I'm not suggesting that. This also assumes a nearly direct free-time focus with at least 10-20 hours of work and QA a week towards a project from each person in a team.

And no thank you. GEOM is decently written, but I'm not screwing with ancient UFS2 code. The conversation between you and me beastie is over. Condescending attitude...

Sure. I can't compare two filesystems. But I was refering to following article. The article is stating that "XFS also consumes about twice the CPU-per-metadata operation compared to Ext3 and Ext4". I've just drawn a conclusion. If the comparision and my conclusion are wrong, I'll take back my words.
Redhat | How to Choose Your Red Hat Enterprise Linux File System

And that's referring to a Linux-specific workload for things that RHEL is working on. I'm not even suggesting build an XFS driver that's similar to Linux's 100% -- it's entirely possible to start with the IRIX-era driver with XFS directory structure v2 and selectively integrate new changes upstream.
 
It was completely unnecessary to apologize. I'm not here to be some 'ackshually' person on XFS or anything else. My goal is to get people talking so someone decides to answer the case for it. If not, then well, it doesn't matter for me in the long run.
 
  • Thanks
Reactions: a6h
It's not a new topic: for FreeBSD if you want to use Postgres for more than just tinkering around, it's either ZFS or begone.

There was even 2020 a talk at the BSDCAN about that phenomenon:

One issue with UFS from that talk:
UFS doesn’t recognise this access pattern as sequential. Linux does, due to read-ahead “window”. ZFS apparently does too.
That talk does not support your contention. The word "apparently" is key there. These are proposed enhancements, not actual ones. There's also this
Joyent reported that both of these things make no sense on ZFS, which
overwrites anyway, so you might as well have a fresh inode rather than one
you haven’t touched for ages that might not even be in memory. They
proposed new settings wal_init_zero and wal_recycle to control that.
•This does indeed seem to improve performance, at least on high latency
media (like my home lab spinning disk arrays).

Again these are proposed, enhancements, not ones that have been made. And even if they are, all COW filesystems are inadequate for OLTP (i.e. heavy write) workloads. See here:
(F2FS and ZFS) provide ~2500 tps, i.e. about half the performance of EXT4. Which may initially look bad, but if you create the EXT4 on LVM and create a snapshot, you’ll generally see ~50% performance drop exactly because you’ve just turned EXT4 into a COW filesystem. So this is actually pretty good - it’s simply a cost for the features provided by the COW design.
So if your application can take a 50% performance hit, by all means, use ZFS. This is not always the case.

With XFS you get a modern journaling filesystem with performance comparable to or event better than EXT4.
 
ZFS is bloated. I like it, I use it, but it's bloated and not suitable for all workloads.



I once emailed Larabel on why he doesn't test UFS anymore, and it's because performance-wise it always trails to the point it isn't worth setting up test systems.
Benchmarks are a crock. You mentioned phoronix so let's use them as an example.
The last I looked at one, many years ago, made me decide he's full of excrement. He takes a custom designed OS, tuned, Linux/GNU distribution and compares it to an out-of-the-box FreeBSD install and muses as to why the latter is slower. Really? Maybe try to set up a system?
He knows nothing of ANY *BSD so he needs to either learn to tune the OS or stop doing benchmarks on *BSDs vs Linux DISTRIBUTIONS.
And look, regardless of whether it's the fastest or not, if people are happy using it, why trash it just as some form of motivation for needing XFS. It doesn't make any sense.

This one you posted is just silly. Their test is FTP? Seriously. What are you testing, your network or your disk I/O? Perhaps ext4's buffering?

(I didn't read the rest).

If you're in denial about UFS2's deficiencies performance-wise, maybe the fact it's not well-documented compared to say, XFS, will convince you.

Every interface of XFS is documented, and its codebase is easy to understand with lots of comments and easy to understand functionality.


Bravo that it's well documented. UFS is not without documentation. However the real question is why this is held against a file system? Why is better documentation a decider in the worthiness of a file system? There's plenty of good file systems that aren't particularly well documented and some are just not at all.

I don't understand this direction of argument. If you're arguing you cannot port it because UFS is poorly documented, then this is just spurious. The code is not that hard to read, there are chapters in books about it so it's not impossible. If you're willing and able I'm sure it can be done.
You have the author available to ask in the mailing lists, as well.



Here's some examples of SGI-derived documentation.

There is no whitepaper on FreeBSD's UFS2, let alone any modern implementation. There's no mutual-intelligibility between the different BSDs UFS2 versions, let alone with the System V UFS. The codebase is ancient, and has been limped along into the modern era. There's been no promises of fixing UFS2. There's been
no promises of improving its performance. People in the community will say "Well ackshually if you want good performance you should use ZFS." and that's a non answer. That's admitting that a filesystem that requires paravirtualizing parts of the OpenSolaris kernel has a massive footprint is superior to your native, default filesystem.

This smells of the same stink that infests gnu/systemd/linux. Once a particular piece of software reaches maturity and is no longer enhanced, bug fixed etc (because it's apparently bug free), then it must be replaced with a shiny new object so that the cycle can continue.
 
I'm not a GNU/Linux shill, Mark. I have no interest in that. I won't however have people tell me how to use my time, my precious time, to try and see what I want as an improvement to the OS. I would like a BSD, any BSD, to adopt XFS under a reimplementation, and for it to be an alternative to UFS. If I ran my own OS, I would remove UFS stuff with prejudice because it's an ancient filesystem that's more akin to ext4 in its poor documentation and understandability. The dual-layer approach it takes (FFS and UFS layers) is also pretty dumb.

So when Beastie7 quite condescendingly told me to IMPROVE THE GEOM/UFS2 CODE because he thinks he knows better than me how to resolve the problems, it definitely doesn't make me receptive to arguments from pro-UFS people.

If you want to say his benchmarks are a crock (and I think Larabel is a kind of shady character whose forum is a horrible place with a strong GNU/Linux bias) that's fine, but you can't use that as a basis to dismiss the criticism. UFS is inadequate, for my needs, and I think FreeBSD could benefit from XFS. But judging from how FreeBSD has been doing boneheaded things in the last 3-4 years, I'm not about to die on this hill for an OS I'm not willing to continue using. Between ZFS crap, the ragecommits regarding Tauthon and other ports, and other dramatics, plus... well there's plenty of users in the community who are toxic, it's not interesting to me. It's why I signed up for development to help with a freebsd fork.
 
This is way backwards, we aren't trying to convince you in anything. We are reminding you that trash talking something doesn't help you find collaborators. Also, you should definitely lead by example and start working on it yourself.

for an OS I'm not willing to continue using
It's why I signed up for development to help with a freebsd fork
Right. Let them deal with idea people.
 
Encryption/Network security is taking a more prominent role. In-Kernel encryption for wireless would be a good place to start.

IBM is bankrolling iwd development and I'm using it with linux in-kernel encryption - I think it will be the future.
 
The last I looked at one, many years ago, made me decide he's full of excrement. He takes a custom designed OS, tuned, Linux/GNU distribution and compares it to an out-of-the-box FreeBSD install and muses as to why the latter is slower. Really? Maybe try to set up a system?
I disagree. The Phoronix guy makes an effort to make sure that the benchmarks are academically valid, and to produce numbers that can be fairly compared. Same hardware, same minimal, out-of-the-box setup, same versions of benchmarks run. You do have to pay attention to make sense of what's being written. 😩
 
"Flatpak" as an idea, some specific technology or Linux binaries packaged with it? That would be 3 different things implementation-wise.

Well, the point would be that rather than investing significant effort into porting multiple programs, focusing all that energy on one gateway app is more efficient. Getting the Linux layer into better shape would be equally compelling. For some of us using FreeBSD as a desktop, there are valuable apps missing.
 
Well, the point would be that rather than investing significant effort into porting multiple programs, focusing all that energy on one gateway app is more efficient. Getting the Linux layer into better shape would be equally compelling. For some of us using FreeBSD as a desktop, there are valuable apps missing.
About a flatpak for linux applications on freebsd is another animal, so...
FreeBSD have a lack of contributors to ports (that's why the valuable apps are missing), so if we have flatpak (which I'm against, since it's a security flaw by itself) we're about to divide the chance of having a contributor to ports with the freebsd-flatpak? I don't think it's a wise idea.
 
This is way backwards, we aren't trying to convince you in anything. We are reminding you that trash talking something doesn't help you find collaborators. Also, you should definitely lead by example and start working on it yourself.



Right. Let them deal with idea people.

To get such a thing working by myself would be near impossible. As I said, I cannot be a project lead. This is a pragmatic approach. if nobody is interested in leading the project, then there's no damn point.

I'm not trash talking. I said freebsd has done boneheaded things. That's not exactly wrong.
 
I'm not trash talking. I said freebsd has done boneheaded things. That's not exactly wrong.
Unfortunately, I have to agree with shkhln ... This is an example of trash talk. And, even if FreeBSD is doing some things you disagree with, it's still your time and your machine. You can set them up the way you like. UNIX is not a religion. 😩
 
Some people seem to think FreeBSD and Linux are on equal grounds. They’re not. FreeBSD is literally a platform derived from highly skilled researchers.

Making bold claims like that without any objective discourse is disrespectful IMO. Not one reasonable deficiency was mention in comparison to XFS. Seriously, atleast give us something to look at.

Read my sig.
 
I disagree. The Phoronix guy makes an effort to make sure that the benchmarks are academically valid, and to produce numbers that can be fairly compared. Same hardware, same minimal, out-of-the-box setup, same versions of benchmarks run. You do have to pay attention to make sense of what's being written. 😩
You're kidding?
The issue is out-of-the-box. He chooses something from GNU/Systemd/Linux tuned for his tests and versus them against his chosen victim. He may use the same hardware and the same meaningless software, but comparing a purpose-built OS to a generic OS like, especially, FreeBSD is just nonsense.
Once bitten, twice shy with that fellow and his "benchmarks".

Anyway, I've polluted this topic enough. It should go back to on-topic.
 
  • Thanks
Reactions: a6h
I'm not a GNU/Linux shill, Mark. I have no interest in that. I won't however have people tell me how to use my time, my precious time, to try and see what I want as

I wasn't saying you were, just that this is the same type of issue that infests linux. NIH==must write our own and stable==must replace ASAP.
That's all fine and good when you drag in 10s of millions of dollars PA.

an improvement to the OS. I would like a BSD, any BSD, to adopt XFS under a reimplementation, and for it to be an alternative to UFS. If I ran my own OS, I would remove UFS stuff with prejudice because it's an ancient filesystem that's more akin to ext4 in its poor documentation and understandability. The dual-layer
What do you want? A file system or an academic research topic?

The so-called dual layer approach was for pragmatic reasons because it re-used a large swathe of code. There's nothing inherently bad about this approach. If I recall correctly, I read McKusick originally looked at XFS but realised it would take too long to get it working under FreeBSD. So, they took UFS1 and made it UFS2. Stable and quick to be developed.

If you want to say his benchmarks are a crock (and I think Larabel is a kind of shady character whose forum is a horrible place with a strong GNU/Linux bias) that's fine, but you can't use that as a basis to dismiss the criticism.
Oh but I can. For the reasons I stated.

UFS is inadequate, for my needs, and I think FreeBSD could benefit from XFS. But judging from how FreeBSD has been doing boneheaded things in the last 3-4

Ok, fine. You've proposed FreeBSD should adopt it. All good. I suspect people take umbrage with the fact in order to justify XFS you trash UFS. I've used UFS in commercial environments from year dot up to and including now. I don't need a whitepaper to know it's rock-solid and does its job. Is it faster than X and slower than Y? I don't know, nor care. (And I don't have a choice in whether it's used or not).

With FreeBSD I think it's: cool kid == ZFS, nerd == UFS. Just saying. ;)
 
Some people seem to think FreeBSD and Linux are on equal grounds. They’re not. FreeBSD is literally a platform derived from highly skilled researchers.

That's 30+ years ago. it doesn't count anymore. That's about the same amount of time that GNU/Linux has been around. Resting on the laurels of the BSD's birthright is akin to a hypothetical son of Einstein saying "I'm the son of Einstein, I don't need to prove I'm smart."

Making bold claims like that without any objective discourse is disrespectful IMO. Not one reasonable deficiency was mention in comparison to XFS. Seriously, atleast give us something to look at.

Read my sig.

I've given metrics indicating that UFS has worse performance, and others dismissed it. I have no sources that will fit someone's criteria, because they have a preconceived notion of what's acceptable. Nothing less than confirmation bias that UFS2 is on equal/superior ground to Linux-based filesystems will work. It's the same as a bad defense attorney trying to dismiss evidence on the basis of bias, but presenting nothing here.

I've mentioned the UFS2 codebase is archaic and difficult to understand. You want support?

Kernel source for UFS2:

Code:
~/devel/freebsd-src/sys/ufs % cloc .
      36 text files.
      36 unique files.
       2 files ignored.

github.com/AlDanial/cloc v 1.90  T=0.17 s (195.8 files/s, 257508.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               21           2645           9399          28793
C/C++ Header                    13            273           1646           1965
-------------------------------------------------------------------------------
SUM:                            34           2918          11045          30758
-------------------------------------------------------------------------------

Code:
~/devel/linux-4.4.293/fs/xfs % cloc --exclude_dir libxfs .
     103 text files.
     103 unique files.
       2 files ignored.

github.com/AlDanial/cloc v 1.90  T=0.18 s (565.5 files/s, 331021.6 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               55           5774          12736          32808
C/C++ Header                    46            796           1714           5760
make                             1              9             24             91
-------------------------------------------------------------------------------
SUM:                           102           6579          14474          38659
-------------------------------------------------------------------------------

Exclusion of libxfs is for direct comparison sake. They're on the surface about the same size, but there's some glaring differences.

1. UFS is organized into much larger files, which can make for difficult reading. This is purely a stylistic choice, but coming from a System V background I prefer this for kernel code.

2. Comments are 36% of the size of the UFS codebase, 38% for XFS.
3. I won't share GPL code, but if you aren't under a prohibition to look at V2 from your employer (I'm not, but I try to avoid v3) look through a few files, read the difference in the quality of comments. Actual comments from each:

UFS:
Code:
    /*
     * Restore user's disk quota because allocation failed.
     */

Code:
/*
 * A virgin directory (no blushing please).
 */
Code:
/*
 * Open called.
 */


XFS:

Code:
    /*
     * Invalidate any cached ACLs if the user has bypassed the ACL
     * interface. We don't validate the content whatsoever so it is caller
     * responsibility to provide data in valid format and ensure i_mode is
     * consistent.
     */

Code:
/*
 * xfs_find_handle maps from userspace xfs_fsop_handlereq structure to
 * a file or fs handle.
 *
 * XFS_IOC_PATH_TO_FSHANDLE
 *    returns fs handle for a mount point or path within that mount point
 * XFS_IOC_FD_TO_HANDLE
 *    returns full handle for a FD opened in user space
 * XFS_IOC_PATH_TO_HANDLE
 *    returns full handle for a path
 */

There's a much higher verbosity in the XFS comments. Much of the files in the ufs code are also directly recycled from the mid-90s UCB code -- the codebase has certainly changed in nearly 30 years but this is not a good sign.

The original XFS implementation in IRIX was much, much bigger (80k+ lines in the kernel) and has been touched and tuned extensively. It's certainly possible for someone to make it even smaller than Linux has it.

As for mark's comments:

I wasn't saying you were, just that this is the same type of issue that infests linux. NIH==must write our own and stable==must replace ASAP.
That's all fine and good when you drag in 10s of millions of dollars PA.

Not that I don't agree, but outright aversion to replacement of a codebase that may take as much money to refurbish is something to consider. By the time someone rewrite UFS to be more acceptable to modern tastes (which necessitates removal of soft updates, as NetBSD did, among a lot more) you will be left with a case of theseus' ship.

What do you want? A file system or an academic research topic?

Nothing I posted was academic in nature. It was papers and docs published by the men who wrote it.

The so-called dual layer approach was for pragmatic reasons because it re-used a large swathe of code. There's nothing inherently bad about this approach. If I recall correctly, I read McKusick originally looked at XFS but realised it would take too long to get it working under FreeBSD. So, they took UFS1 and made it UFS2. Stable and quick to be developed.

Design decisions made 30 years ago need to be questioned man. Why has nobody else other than the BSDs done this? Why did all the System V UNIXes go on to develop their own proprietary filesystems and discard UFS (Hint hint, it's not licensing!). This design has obfuscated code that desperately needs to be understandable.

As for your comments... here's my problem and a problem that in large part extends to other debates:

Someone sets an impossibly high burden of proof/quality of evidence. When the person struggles or fails to offer proper evidence, the original person declares "I WIN" by default. This is not a court case, you are not iudex, jury, bailiff and such. We are having a debate, and you have to actually go in and debunk what's said -- which by and large you didn't do, and netiher has anyone else. It's also worth noting that if you apply what I just said to non-technical topics, it immediately shows the weakness in not entertaining ideas brought forth. Frankly, I'm not here to convince you XFS is the way to go -- if you've made up your mind it isn't, then so damn be it. I want someone to see this who may have the skills to lead such an effort, and say "Hey he's got a good idea, and he's offered to help on some capacity. Let's talk and see what we come up with." Which would be swell. I'd gladly consider that, though I'd insist my work be done on the freebsd fork I am doing work for rather than the direct upstream. I won't ever deal with the FreeBSD upstream again after seeing the gross problems that are weighing down the project and causing boneheaded decisions to be made.

IN CONCLUSION

I've stated all on the topic I feel inclined to. You have the evidence. I'm not the jury, you're not the jury. Make your mind and grow up, if you got angry or emotional over me attacking or questioning code that's been taken for granted and is trash IMHO, then you should re-evaluate things
 
Some people seem to think FreeBSD and Linux are on equal grounds. They’re not. FreeBSD is literally a platform derived from highly skilled researchers
That's true, Linux dominates market segments like Top 500 super computers with 99.6% market share, so High Performance Computing, where FreeBSD is not even a thing. It's also supported on IBM mainframes, where IBM itself did the port.
 
Back
Top