"the GNU/Hurd is Unix(POSIX)-compatible, so most things work"... well that's to be said for MacOS, QNX, etc. In practice, where is the "65% of the Debian archive can be built for the Hurd" figure coming from? I'm sure it can be built in theory, how much does it require source modifications?
And here's the overview on how many packages have successfully been built vs how many have failed: https://buildd.debian.org/status/architecture.php?a=hurd-i38...
The number of packages that can be built have been built; it is not a theoretical number.
I don't have anything recent, but back in 2004, the majority of the Linux kernel code was in its drivers: https://dwheeler.com/essays/linux-kernel-cost.html I expect that most of the current Linux kernel code is also for handling hardware (that is, drivers + the code to handle various architectures).
In short, hardware is more capable, and so perhaps now we can afford to take more opportunities to trade a little bit of overhead for abstractions that are more modular and robust.
We could afford that before, it's just that Linus didn't see the value and put his foot down. Which is definitely a choice.
They aren't general purpose, but I presume microkernel "services" would also not be general purpose?
they are seldom implemented correctly on firmware/mainboard level.
On the other hand, datacenters have become so large that a 1% performance improvement can amount to millions of dollars in hardware and energy savings, so the extra cost of a microkernel might not be very welcome outside consumer devices.
Microkernels have won, even if monolitich kernel advocates haven't yet got the message.
Not to forget all the hardware based security bypasses that let any random application read and even modify any memory location it wants to.
The basic problem is that the kernel boundary is a trust boundary. You assume that anything in the kernel is legit and won't try to attack you, which simplifies things a lot. In the microkernel world the original idea was that all the servers would be just ordinary programs you could swap in and out at will. But then the threat model becomes muddied and unclear. Is it OK to run a server that's untrusted? If so, to what extent?
The Hurd seems under-designed as a consequence. To make that vision work you'd need to be willing to depart from UNIX way more, which really means being a research OS.
No, of course, it doesn't automatically do so. But it makes it a whole hell of a lot easier to write a reliable service, if you don't have to deal with all the crap that a monolithic kernel does.
I think you'd find Plan 9 interesting. It deals with many of the issues you're talking about in a rather head on way. In fact, it takes things even further than Hurd might, and allows processes to migrate to different processors, which may be contained on completely different machines.
2. Modern day hardware is mostly just ringbuffers mapped to memory. There's a real convergence of hardware interfaces, virtio, and io_uring into all being this very similar looking thing. With IOMMUs, moving drivers to userspace is pretty attractive. There's not much of a difference between a cloud VM getting access to a VFIO device from the hypervisor and a userspace device driver getting access to hardware from the microkernel. And there's a lot of money in making cloud VM networking & storage faster.
Check out Antti Kantee's The Design and Implementation of the Anykernel and Rump Kernels if you want details on the architecture.
> You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.
Just because the driver creator is a different human/org to the Kernel maintainers, doesn't mean their code needs to be separate if it makes more practical sense to bundle it all together.
Also the "proof of work" of being allowed to add your driver is probably that you are designing and producing actual hardware, so it is hard to troll.
At this point I don’t remember the last time I’ve compiled a kernel.
Really, the speed of compilation is such that I understand why so many source distribution methods are as popular as they are now. Feels funny to have come to that point so effectively.
I haven't built my own kernel for more than 15 years, but I probably built more than a dozen before that, each of them re-compiled upon every new release (going back to 0.98).
To that end, how different is it, actually? And what are the other tradeoffs?
Ask yourself why it's safer to use FUSE filesystems on Linux when mounting untrusted block devices/image files than the in-kernel filesystem drivers and maybe it'll become clear why this is advantageous.
Or if you're familiar with containers and why that's a good thing, you can think of it as containerizing the kernel's subsystems/drivers.
Pointing at literally decades of device drivers as why the size of the code is bad, while acknowledging that it will take time to write device drivers so this will work on a respectable amount of hardware just feels weird.
That all said, please don't take this as a criticism of any of these ideas. I confess seeing Hurd in the headlines gave me a smile. Is nice to see people can still work on many ideas out there. I am only questioning the "size of code bad!" right next to "it will take us a long time to replicate a large portion of the code we just pointed at."
It would be more robust because individual services could crash and restart. That could really work for, say, WiFi drivers. It doesn't quite work for disk drivers or the file system, since how do you even restart something without a file system?
It would be more secure because drivers would live in isolated memory spaces. So a non-critical piece like a printer driver couldn't read memory from something more critical like a file system. Part of what changed since microkernels were originally proposed is that drivers are often split into low- and high-level parts. So a printer driver in Linux consists of a standard USB or network driver in the kernel, plus a user-level driver that can be worked on like a microservice. And the WiFi driver is a low-level driver plus wpa_supplicant running at user level. The USB and network drivers are shared with critical services, so you can't easily restart them anyway.
It would be easier to develop because you can restart just the piece you're working on without rebooting the whole kernel. That's a plausible argument, but somewhat undermined by HURD taking 30 years to develop. But there were many other reasons for that.
I guess the way to convince yourself one way or another is to try writing a driver for both.
And "drivers" could just restart is laughable with a role play of it. Ok, your wifi driver restarted. What are the protocols to get everyone caught up between that driver and your application for what messages were lost and the messages that are now arriving? This is effectively no different from any distributed application where similar things are unsurprisingly hard to achieve well.
I'll state that I think this is a laudable goal. And I'm happy to see people working on it. Would be thrilled to be shown I'm wrong.
There are plenty of applications out there that just don’t respond to configuration changes gracefully. For example, if you have a music program running, and then you plug a MIDI keyboard in, is the new MIDI keyboard recognized by your music program? Maybe so, and you can use it immediately. Maybe not, and you have to restart the application.
If your MIDI driver crashes, maybe the music program doesn’t handle it gracefully, and you have to quit and relaunch the program. But that is miles better than crashing the system and rebooting.
MIDI is actually an easy example, all told. If I unplug and replug a keyboard in, I expect it to probably not handle any persistent state of the keyboard correctly. (For fun, it is common for the "at rest" value of peddles to be discovered at connect time. Good luck with that if the driver crashes.)
The application already knows that the data is not guaranteed to be delivered, or even sent at all. That’s just the nature of network programming—it’s inherently unreliable.
> And if I have to have secrets in the driver for it to be able to connect to access points and such, it seems dubious how protected from all of my secrets the system can be between all parties.
To make an analogy—locking your front door doesn’t protect thieves from stealing your plastic flamingoes and garden gnomes, but it does make it harder to steal the $50,000 in cash you have hidden under the mattress.
The point of isolation is to reduce the effect of failures. If you have a buggy WiFi driver, in a monolithic kernel, that could be really bad—it could even be a remotely exploitable vulnerability in the kernel itself. In other words, you have no front door, and the thieves can steal the $50,000 hidden under your mattress. If your WiFi driver is unprivileged, then the thieves have only broken through your front gate, and they can only steal your garden gnomes and plastic flamingoes. They need to combine the vulnerability with a local privilege escalation vulnerability, or be happy with the value of plastic flamingoes.
> For fun, it is common for the "at rest" value of peddles to be discovered at connect time.
The keyboard itself does this, either when it’s turned on, or through the configuration menu (or not at all). It’s not something that has anything to do with drivers or connecting the keyboard.
We /could/ turn all computation into remote procedure calls. There is plenty of precedence that that will not end well. You do it where you have to. Not everywhere.
And fair point on the device learning its "off" position at startup. Though, that really leans into another point I made in another branch. That level of "isolated and can restart" is already largely accomplished by having extra compute on the devices you are connecting to. I really can't see much benefit it doing everything in the RPC paradigm.
I get the promise. I'm not buying the evidence that you can solve this by making it transparent that all things are "servers" and some are remote.
Generally they are—when you make an HTTP request, the client waits until it receives an HTTP response before it reports success.
> We /could/ turn all computation into remote procedure calls. There is plenty of precedence that that will not end well. You do it where you have to. Not everywhere.
I think you may be having some kind of a different conversation here. I don’t understand your position, and I don’t think you understand mine.
There are good arguments for this in some environments.
pedals
> to be discovered at connect time.
TCP?
There is a good article somewhere about how you have to do end to end for any of this to really work.
That said, I don't make too big of a defense of networking being a bad choice. At large, that is literally where you have to do distributed computing anyway; so, agreed a lot of it will be covered for a lot of applications. I was trying to stick to the examples others chose as I'm not really trying to "gotcha" to anyone. My main point was honestly more about how similar that is to how we are today. If you were in a microkernel, is it any easier? Because that is the original goal post here.
I do further question why you'd want to do that for every subsystem interaction, and if you really want to have to redo all kernel context swaps and local message passes if something went wrong locally.
1. Linux is too big. Even if we exclude the drivers, which are a majority of the kernel codebase, linux is still a massive kernel. Most microkernels are small enough to fit in the L3 cache, some are small enough to fit in the L2 cache. Linux, even if we could exclude the drivers, doesn't even come close. This inability to fully cache the kernel ends up negating the primary benefit that monolithic kernels have, which is performance. Linux spends more time bouncing around the cache than a modern microkernel takes to do an extra syscall.
To add to this, unless you are compiling your kernel specifically for your machine, your kernel is going to be a bloated compromise of the set of drivers that your system is most likely to see. That means that you will have dozens, if not hundreds of drivers compiled into your kernel which will never need to be used.
It's also too big in the sense that there are now far too many lines of code to be able to effectively monitor for vulnerabilites. That codebase size won't change when having a microkernel with the same number of drivers, but what will change is the ability of a single vulnerability to compromise your whole system. You have effectively compartmentalized vulnerabilities to their own address space. So in that sense, big codebases are a huge problem for monolithic kernels, but only a small problem for microkernels.
2. It will take time to write a ton of device drivers, simply because most of them aren't written yet. To that extent, Linux most definitely has an incumbent advantage. But that isn't to say that microkernels also have an advantage here. Anyone who has written a driver knows how much the ability to iterate quickly is helpful. Drivers in userspace can be written directly on the system that they will run on, with no virtualization or kernel reboots necessary, and with incredibly fast start/restart/stop. Userspace drivers are dramatically simpler to write, simpler to build, simpler to monitor, simpler to test, and simpler to distribute.
With all that being said, I definitely don't think Hurd is the future. But what could change the world is already out there but not really ready to use at the moment. One possibility would be an open-sourcing of QNX which is an amazing and incredibly mature microkernel OS, possibly the most mature in the world. If there are any bored billionaires out there reading this, please buy QNX from Blackberry and do that. Another possibility would be to put a shit ton of effort behind the SeL4 userspace, which is just too damn hard to do anything practical with at the moment.
I imagine there's two pools of Linux users: those that compile their own kernel, probably with only the drivers they use; and those that use distribution kernels, which have a small set of compiled in drivers, and a huge initrd with all the drivers. Neither one of those groups ends up with all of the drivers loaded into memory: the compile their own have a small set, the distro kernel people end up with only the drivers they need loaded; both groups have a relatively small kernel footprint.
Have you looked at the size of L3 caches lately? You could fit a whole ‘nother OS in one of those.
Process isolation and selinux are things that exist. You even mention it. Turns out, having complete isolation between basically everything in your system is hard. I don't see how microkernels will make that difficulty disappear?
You can ask for numbers without casting aspersions like that.
This is HN. It is something like a casual conversation. You are free to ask for numbers, other people are free to provide or not provide them, and we should be able to have this conversation without leveling accusations of dishonesty (which the word “feels” does not really temper).
I was actually trying to find the numbers myself, and it was surprisingly more involved than I'd care for. I didn't want to give someone else more work, but happy to see the numbers expanded. I stand by my criticism, though. It feels off. If you want to say it is justified, spend more effort justifying it.
The phrase “it feels” is not carte blanche to say what you want.
I could say, “Someone reading this post might think that you’re an axe murderer.” Certainly not me, I don’t think you’re an axe murderer. But someone reading this post might think so. What this does is introduce a new topic of conversation—that topic is you, and whether you’re an axe murderer. I’ve done it without saying anything untrue. It is literally true, that someone reading this post might think that you’re an axe murderer. That has much the same effect as an accusation, but I’ve given you no real way to respond.
When you write “it feels”, there is an implied subject, who is feeling those feelings. That subject is you.
I flat out feel it is dishonest, in the vein that it is cherry picked data to further support a point that they agree with. Such that, using "this is a casual conversation" as a rubrik, I absolutely call BS from people when they say stuff like this to me.
If this was a "town square debate" where the conversation is partisan and folks are trying to score points, I'd agree with your assertion a bit more. But for casual conversation specifically, I ultimately reject this view.
Now, if the poster is specifically offended, I'm more than willing to apologize on that and to clarify my point. I had no ill things to say about the poster or the main topic. Heavily critical of cherry picked data, with a justification of why.
No, actually quite the opposite: Reductio ad absurdum is a form of logical proof, not a fallacy.
Process isolation actually isn’t fundamentally hard…it’s just hard on a system that wasn’t designed for it. And SELinux doesn’t do what microkernels do. Even with a tightly locked down SELinux configuration, a driver vulnerability can lead to root access. SELinux can protect your userland the same way that microkernels do, but it can’t put your drivers in userland.
I do question if process isolation isn't fundamentally hard. Separate processes for separate things entirely is not fundamentally hard. That, I agree. But, so much of what we do is integrated together. Is why early attempts to make it so that some programs can't see my whole hard drive are bonkers annoying. I specifically want access to the picture I just saved in that editing program so that I can email it.
In this case they’re both old though, as Hurd predates Linux by a year.
With drivers:
---------------------------------------------------------------------------------------
Language files blank comment code
---------------------------------------------------------------------------------------
C 32699 3332747 2610014 17218820
C/C++ Header 23690 712617 1373965 7109290
Assembly 1336 48534 101884 234314
---------------------------------------------------------------------------------------
Language files blank comment code
---------------------------------------------------------------------------------------
C 13200 1031558 951267 5356551
C/C++ Header 13760 300309 535100 1643611
Assembly 1321 47500 100899 230638
Numbers obtained by running cloc 1.96 on current kernel master.
I think many are misunderstanding my criticism here. I offer it more as a way to strengthen the message than I do to question it entirely.
To that end, the only "goal post shift" I would add is to ask how many of the 17 million lines of driver code have to be done for Hurd to support hardware that would make it more relevant for a ton of users?
Probably? If you really want an apples-to-apple comparison, delete everything but x86_64 support from both Linux and Hurd. Remove sample code.
linux/net isn't strictly "drivers", but implements the base of the networking stack. That's 900k lines. Is that networking base code included with the Hurd figures? If not, delete it (or include in your comparison Hurd's base networking code).
Beyond that, this is getting a bit ridiculous. Who cares about the LoC comparisons? They're very different kernels with very different levels of maturity and number of features. I'm not even convinced you can call one "better" or "worse" based on this metric at all.
Is that important, though? As soon as you start processing any meaningful amount of data, won't your OS be evicted from the cache anyway?
> unless you are compiling your kernel specifically for your machine, your kernel is going to be a bloated compromise of the set of drivers that your system is most likely to see. That means that you will have dozens, if not hundreds of drivers compiled into your kernel which will never need to be used.
I'm not sure this is true. Device drivers are typically compiled as modules, which are only loaded into the kernel if needed. Common wisdom among Linux power users for the last decade or so has been that compiling your own kernel for any tangible performance/memory improvement is basically futile.
Are there exceptions to this that you are aware of, and can elaborate on?
Writable caches yes. However many (most?) modern processors also contain an code-only cache which can be used for OS caching without any need to flush. The raspberry pi 4 can fit many modern microkernels in their tiny immutable cache, so it gains a massive caching benefit by being small.
> Are there exceptions to this that you are aware of, and can elaborate on?
You’re probably right, I was unaware of the extent of the kernel module usage. Regardless, the smallest common kernel in use that I know about is for alpine Linux and that is still at least 100MB, which is dramatically larger than the <1MB microkernels that are typically available.
OK then, so, which microkernel provides performance on-par with or better than Linux?
This is a strong claim and some evidence is warranted.
Syscall latency also is not the end-all-be-all of performance. Does that actually translate to faster disk and socket I/O on average?
Syscall latency is definitely not the end-all-be-all of performance, but it is all there is to compare between a monolithic kernel and a microkernel. In both cases, driver code needs to run, and that driver code can be good or shitty just like everything else.
When it comes down to it, the syscall latency that is comparable is the context switch between privileged and unprivileged mode. The holy grail of microkernels isn't to be faster than macrokernels, it is to be just as fast, but a hell of a lot more modular, usable, and secure.
That depends on what you're doing. If you're running some digital signage display or whatever, no one cares about a missing display frame or whatever. But if you're running a car's HUD or, worse, its steering system, you absolutely need the execution time guarantees or your code won't make it past certification.
This makes no sense. The comparison that matters isn't kernel vs microkernel, its kernel vs microkernel plus all the userland code needed to implement system services. If my program wants to read a file and write to the network, then the code to do that has to be brought to the CPU to run before my program can finish doing that, and it doesn't matter whether that is in the kernel or userland.
And also, what matters for performance is the size of the "hot" code. A lot of code, both on a monolithic kernel and on the userland code implementing system services for a microkernel, is going to be "cold" code which executes rarely. This includes initialization code, shutdown code, most of the error handling code, code to react to uncommon hardware events, and so on.
> If my program wants to read a file and write to the network, then the code to do that has to be brought to the CPU to run before my program can finish doing that, and it doesn't matter whether that is in the kernel or userland.
And given that the essential complexity is the same, it's very likely that the size of the relevant code is similar.
The reason microkernels typically benchmark on syscall (typically IPC) latency is because that is the only truly apples to oranges part that you can't compare between the two. Monolithic kernels have a single context switch, microkernels have two. But microkernels, being micro, are a lot friendlier to caches (less to load and flush), and especially so with dedicated code caches (which do not need to flush on context switch).
So even if you have a really large monokernal the parts of it that actually get used will be in cache in the parts that aren't used and won't be in cache.
Has other people stated how Michael Colonel is still going to need a lot of user modules to do most of the work that's normally in the monolithic kernel, so it'll probably end up being about the same amount of code that needs to be in cash first, not in cash. The differences is really come down to just call boundaries as I understand it
Too big for what exactly? Because it's clearly not too big to run. It's been running very well for decades, and Hurd has not.
I've known for decades that on paper, microkernels and Hurd should be superior, and I've wondered for nearly as long why then they aren't taking off. If they're so good, they should at least be thriving in some niche where that performance matters, shouldn't they?
And now I hear that even after 3 whopping decades, it still doesn't run on real hardware! Entire operating systems have been born and died in that time.
What is the problem that's making Hurd still not work?
> 2. It will take time to write a ton of device drivers, simply because most of them aren't written yet. To that extent, Linux most definitely has an incumbent advantage.
But why is Linux the incumbent when Mach and Hurd were conceived 3 years earlier?
> But that isn't to say that microkernels also have an advantage here.
I would love to believe that, but then why has that advantage not paid off for 30 years?
> With all that being said, I definitely don't think Hurd is the future. A Why not? And is this why nobody has been writing those drivers?
I don't mean to be shitting on Hurd, but it's been really promising for so long, and not delivering, that it's starting to feel like fusion power: always in the future, nearly there, but never quite here.
They (microkernels) thrive in Automobiles, Aircraft, Spacecraft, Security systems (such as hardware encryption devices), Defense Munitions, Embedded Devices, Maritime devices, radar systems, and many other areas. The common thread here is that they are not just resource constrained and performance sensitive, they are also typically very specialized and mostly write-from-scratch.
That last part is the key to understanding why general purpose operating systems mostly use legacy kernels that are decades old. We want to preserve as much as we can from what came before.
> But why is Linux the incumbent when Mach and Hurd were conceived 3 years earlier?
Because Linux worked earlier. Nobody in the GNU ecosystem knew how to develop a microkernel that worked, let alone drivers for a constantly changing target OS.
> I would love to believe that, but then why has that advantage not paid off for 30 years?
Again, they have. Almost all RTOSes are microkernels, and the most popular embedded OSes are microkernels. When you're writing something from scratch, it is always going to be easier with a microkernel. Don't mistake Hurd with the concept of a microkernel. Hurd sucks because it has always sucked. It's bloated, poorly documented, relies on a very janky GNU ecosystem that has already mostly adapted to Linux out of practicality concerns, and there is no ecosystem tooling around it.
But the advantages of microkernels in general are very real. The best one out there in terms of maturity is QNX, and while practically every modern car on the planet runs on it, it's licensing pretty much precludes it from being used as a general purpose OS.
But it's not being used there in current mainstream production.
https://www.meaa-mea.com/advanced-mobility/
https://www.blackberry.com/us/en/success-stories/mitsubishi
It's certainly difficult to pick through the Blackberry QNX hype to see where it's actually headed outside of infotainment, lot's of fuzzy weasal phrasing:
https://blackberry.qnx.com/en/industries/connected-autonomou...
Outside of some vague blackberry press materials, I've never seen anything specific.
Outside of some vague blackberry press materials, I've never seen anything indicating use in vehicles.
Or could they work if only people would stop focusing on Hurd? Is Hurd a dead end? Or is GNU the real problem and should we abandon that?
Out of all of the microkernels out there, the one I like the most is SEL4, but the security model is so different from most OS kernels that you essentially have to program for it from the ground up. And it seems like there isn’t any momentum there either. QNX is already very mature and performant though, and it has gotten a huge boost from IoT and electric car development, and IMO all it needs is an open source license and it will eventually creep its way into general purpose OS usage.
Yes, it's old. Yes, there's only little interest. Yes, there are _still_ many technical problems.
The interesting thing here is that technical problems can be solved, and will be solved given enough time. Heck, I've heard rumors that even Windows does not crash multiple times a day anymore.
Focussing and working on what is popular will most likely create a world that is less free every year. Some people rather work on something that seems right and promises a better, freer future. Even if it's not popular (right now), even if it has a high probability of failure.
Popularity is a very volatile property...
And popularity might be a double edged sword, but double edged swords are still useful if you're careful.
Although keeping software proprietary or writing proprietary software may have become somewhat unpopular in some niches (I'm not sure it's incredible unpopular seeing how many people and institutions still use and often advocate Apple, MicroSoft, use FaceBook, WhatsApp, whatsnot...), I'm not yet convinced that many people (say more than 1%) really believe that all software should be free and act on that?
These days most Linux distros build pretty much any driver as a module that can be built as one. Boot-critical modules (like NVMe drivers) are included in the initramfs so they're available before the disk is mounted.
I agree that Linux is still larger than a microkernel, but very few users have a bloated kernel in RAM due to lack of customizations.
Most users run the distribution's kernel.
The rest is in the modules and they're not loaded unless they're actually used.
What could possibly go wrong.
So yeah, in the ideal world, let's have everything isolated. For now it would be great if they worked at all.
Also... There's a bit of practical limitation to how useful the isolation is. It's cool that the FS module runs in the userspace. But if it can create a suid-equivalent file and point an arbitrary config at it, you're not gaining much.
I am not going to pretend I have any idea because I have just googled these numbers but it seems to me that an amount of cache could be reserved for the kernel without too much of a hit to applications on what are currently high end machines.
For Linux, yes. For a microkernel, those are different trees of userspace software.
Not to say, Hurd itself is userspace software, that runs over a microkernel (included on the distribution).
If that were the argument, then the comparison with Linux would be meaningless. Hurd is much bigger than freertos, should everyone switch?
https://upload.wikimedia.org/wikipedia/commons/f/f5/Sankey_D...
It is interesting that the “remainder” chunk of the drivers is so big. Wonder if they need some more categories.
On the smaller side, Ext4 at just 21,515 lines, and on the larger side, Btrfs at 55,758 lines.
It almost makes me think that writing a new file system in Rust, might actually be a tractable project.
Here are my criticisms :
1) LoC doesn't indicate complexity. When you're looking at a code base and you see that it's 65000 lines, that by no means should be an indicator of whether or not a re-write is easily feasible -- especially with a filesystem.
2) Language shouldn't be a motivator for a re-write without considering why the language offers advantages, the end users don't care about which file extension is littered across the source tree.
Both of those tendencies (one to re-write everything in your favorite language, and two to come across with an idea that you understand how complex a mechanism is simply from LoC) indicate to me, anecdotally of course, a certain lack of experience; and I have a hard time imagining someone with those concerns tackling a re-write of a filesystem that gains 'the audience' any benefits.
If it's just for the sake of personal toys and fooling around with your own machine I feel as if those motivations are fine, but I have concerns if 'a new filesystem in Rust' comes from what I view as shaky initial motivations.
Look, I'm as into cool FS-hacks as anyone, but writing a new filesystem has 99+ problems and the language used is either the last of them, or it isn't even in the set.
Granted, you could (on Linux) write a little pseudo-filesystem (e.g. /proc or /sys) and not face any of the issues involved in extN or btrfs etc. I didn't get the sense that this was what the OP intended, but I could be wrong.
Many of the worst bugs (data loss and corruption)? Probably.
Having something like the Rust borrow checker around to make sure you don't make dumb mistakes is handy, to be sure. But, let's not oversell it as some kind of panacea. I bet I could write a FS in Rust with all kinds of bugs, and the borrow checker wouldn't be able to stop me.
Obviously ext2 is a very outdated filesystem by today's standards, but considering ext3 and ext4 are essentially just some extensions slapped onto ext2, I still didn't expect it.
Another thing I found really impressive was just how resilient e2fsck is. During early development of my ext2 code I frequently mangled the file system in a myriad of weird ways, but no matter how much I broke things, e2fsck was almost always able to restore the file system into a reasonable state.
(For the curious, there is some excellent documentation on the ext2 file system at https://www.nongnu.org/ext2-doc/ext2.html that I mostly used for my implementation of it. Sadly no such thing seems to really exist for ext3/ext4).
When people tried to do a full-featured filesystem, with a remarkable exception (ZFS) it's either a disappointing unfinished mess (btrfs) or a promising, but a long-term project taking years (bcachefs).
Making a filesystem with strong support of important features is an extremely demanding project.
Lines of code isn't the only important metric. A project with a smaller number of LoC can take a long time to fully test and debug and validate.
45KLOC of C code already sounds really scary to me, although yeah, journaling is really nice to have.
About the only class of scenarious to use BTRFS instead of ZFS is if you want the features, do not need RAID5/6, require support by Linux distributor/kernel developers or for some other (hard to think of) reason you can't use ZFS.
https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...
What's harder is making them as robust as they need to be for practical daily use. Doing that is a matter of comprehensive testing, though. With filesystems, the hard part is QA, not implementation.
For real world use wheen comparing OS you would generally go for other metrics like resource usage, multi threading bottlenecks, throughput of network packet and their processing, context switches(or equivalent) per second, and dozens of other things that would be paragraphs in length before you get to LoC.