> btrfs is still around only because ZFS can't be mainlined basically

ZFS is extremely annoying with the way it does extend and the fact that you can’t mismatch drive size. It’s not a panacea. There clearly is space for an improved design.

I've never had any issues with either ZFS or Btrfs after 2020. I wonder what you all are doing to have such issues with them.

The community is still growing (developers too!), and people have been jumping in to help out with getting DKMS support into the distros.

bcachefs isn't going away.

The SuSE guy also reversed himself after I asked; Debian too, so we have time to get the DKMS packages out.

I switched to ZFS for a while but had to switch back because of how much was broken. Overlayfs had issues, reflinks didn't work, etc. Linux-specific stuff that just works on kernel filesystems was missing or buggy. I saw later they added support for some of the missing features but they had data corruption issues. Also I doubt it'll ever support fs-verity.

I don't plan on giving ZFS or other filesystems not designed for Linux another go.

Might be harder to keep running ZFS on Linux after 6.18

https://www.phoronix.com/news/Linux-6.18-write-cache-pages

Wait. You don't trust Btrfs but you would trust BCacheFS, that's obviously very experimental?

btrfs has many technical advantages over zfs

Yeah, this all seems so unnecessary. I hope Kent can either figure out how to work in the context of a larger team or find somebody who can do it on his behalf.

Same. I liked many of its features (actually, all features, see https://bcachefs.org) and I was waiting for it to become usable, but I guess that day will never come now?

So, the alternative is ZFS only, maybe HAMMER2. HAMMER2 does not look too bad either, except you need DragonflyBSD for that.

I think this would be the most usable microkernel these days, and yes, it does FS as a service: https://www.redox-os.org/

There's no inherent reason why a filesystem in userspace has to have a measurable performance impact over in-kernel, done right. It would be a lot of engineering work, though.

Context switches aren't that expensive when you're staying on the same core, it's IPIs (waking up a thread on another CPU) that's inherently expensive; and you need zero copy to/from the pagecache, which is tricky. But it totally could be done.

So FSKit is public API and supports userspace filesystems but on macOS most built-in filesystems are kernel modules. On iOS everything except APFS is userspace.

Modern Darwin is mostly a monolithic kernel, though more and more things are moving to userspace where possible (eg DriverKit).

One interesting side-effect of various spectre mitigations is silicon improving the performance of context switches. That has the side-effect of decreasing the cost of kernel/userspace transitions. It isn't nearly as expensive as people still believe - though it isn't free either.

If there was a usable microkernel, then its filesystems would almost certainly be implemented in userspace; that's kinda the point of a microkernel. I can't speak to how Darwin does things, but I will point out that Linux and the BSDs have filesystems as userspace processes courtesy of FUSE; in their architecture that has a performance hit (caused by the context switching needed, I believe recently improved by use of io_uring), but it is a worked example of what you want.

Sounds like what bcache does? https://bcache.evilpiepirate.org/

This is what bcachefs is based on.

Very recently I setup a mergerfs mount for this. It’s very crude for my use case but works perfectly and I could use the existing volume as is.

I got partway thru setting up a script to copy recently accessed files from the HDD to the read-prioritized SSD.

My LLMs load up way faster, and I still have a source of truth volume in the huge HDD. It’s not something I’d use professionally though, way too janky.

> All of the "btrfs eats your data" bugs have been fixed ... I have a btrfs on my home file server that's been running just fine for almost 10 years now and has survived the initial underlying hard drives mechanical death

In the last 10 years, btrfs:

1. Blew up three times on two unrelated systems due to internal bugs (one a desktop, one a server). Very few people were/are aware of the remount-only-once-in-degraded "FEATURE" where if a filesystem crashed, you could mount with -odegraded exactly only once, then the superblock would completely prevent mounting (error: invalid superblock). I'm not sure whether that's still the case or whether it got fixed (I hope so). By the way, these were on RAID1 arrays with 2 identical disks with metadata=dup and data=dup, so the filesystem was definitely mountable and usable. It basically killed the usecase of RAID1 for availability reasons. ZFS has allowed me to perform live data migrations while missing one or two disks across many reboots.

2. Developers merged patches to mainline, later released to stable, that completely broke discard=async (or something similar) which was a supported mount option from the manpages. My desktop SSD basically ate itself, had to restore from backups. IIRC the bug/mailing list discussions I found out later were along the lines of "nobody should be using it", so no impact.

3. Had (maybe still has - haven't checked) a bug where if you fill the whole disk, and then remove data, you can't rebalance, because the filesystem sees it has no more space available (all chunks are allocated). The trick I figured out was to shrink the filesystem to force data relocation, then re-expand it, then balance. It was ~5 years ago and I even wrote a blog post about it.

4. Quota tracking when using docker subvolumes is basically unusable due to the btrfs-cleaner "background" task (imagine VSCode + DevContainers taking 3m on a modern SSD to cleanup 1 big docker container). This is on 6.16.

5. Hit a random bug just 3 days ago on 6.16, where I was doing periodic rebalancing and removing a docker subvolume. 200+ lines of logs in dmesg, filesystem "corrupted" and remounted read-only. I was already sweating, not wanting to spend hours restoring from backups, but unexpectedly the filesystem mounted correctly after reboot. (first pleasant experience in years)

ZFS in 10y+ has basically only failed me when I had bad non-ECC RAM, period. Unfortunately I want the latest features for graphics etc on my desktop and ZFS being out of tree is a no-go. I also like to keep the same filesystem on desktop and server, so I can troubleshoot locally if required. So now I'm still on btrfs, but I was really banking on bcachefs.

Oh well, at least I won't have to wait >4 weeks for a version that I can compile with the latest stable kernel.

The only stable implementation is Synology's, the rest, even mainline stable, failed on me at least once in the last 10 years.

"performant", it's still slow if you actually use any of the advanced features like copy on write.

> FUD all around

????

> Don't do RAID 5.

Ah, OK, so not FUD

> Stop parroting lies about btrfs.

I seee

Yeah, no. I've had btrfs lose a root filesystem on a laptop with only one disk. No RAID, nothing fancy, well after it was supposed to be stable, on OpenSUSE where I assumed it would be well supported and pick good defaults.

Claiming that anyone reporting problems is lying is acting in bad faith and makes your argument weaker.

Also, "works for me" isn't terribly convincing.

There is an apology for that comment and a rewording further down the thread. Evidently made by someone who is not a native speaker who did not realise how it comes across.

"behave" in this context can refer to simply respecting existing norms about RC code freezing.

How cynical. It's the bcachefs maintainer, not the kernel maintainer, who does not behave and has a huge history of unprofessional behavior for decades.

it is not like he was not explicitly warned.

The bcachefs maintainer has added new features during bugfix windows, and lied about it.

The original author later sent an apology email explaining that it sounded too harsh in English and it wasn't meant to be offensive:

https://lwn.net/ml/all/bece61a0-b818-4d59-b340-860e94080f0d@...

There was a time when Linus encouraged critics of "unprofessional behavior" to snap back at him:

https://lkml.org/lkml/2013/7/15/374

That is a reasonable compromise. Except when someone actually snaps back at him.

The reason is that people like Linus, because he's entertaining. And people don't like Kent, because he opposed Linus, who is liked. That's all there is too it. Like in some high school.