8 ms·

BCacheFS is being disabled in the openSUSE kernels 6.17+

70 points by 6581 1y ago

lupusreal 1y ago
The way the BCacheFS situation has been playing out is a tragedy. I had very high hopes for it.
- InsideOutSanta 1y ago
  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.
  - johnisgood 1y ago
    > Once the BCacheFS maintainer behaves [...] So, there are still behavioral issues here I take it? That is a bummer. This is not news to me, but I thought the situation has changed ever since.
    - motorest 1y ago
      > So, there are still behavioral issues here I take it? From the past discussion, it's mainly grave behavioral issues but they also end up being technical. Such as trying to push new untested features into RCs and breaking builds, and resorting to flame wars to push these problematic patches forward instead of actually working them out with maintainers. But yeah, the final straw was a very abusive email sent to a maintainer in the mailing list.
      - koverstreet 1y ago
        ...Where are you getting this stuff? Seriously, every time I read tales about all the horrific things I've done in the kernel community, the stories grow and get wilder and wilder. Oh wait. It's you.
        johnisgood 1y ago
        That is just people for you. My advice would be to not let them prompt you to leave such comments because it will appear to confirm what they are saying.
        koverstreet 1y ago
        In my experience, the trolls never go away unless you start poking at them to point out how ridiculous and laughable they are.
        InsideOutSanta 1y ago
        One thing I've learned over 40 years of working in software development is that it is often more effective to collaborate productively with others than to be right. Maybe Linus's rules for what can be merged at what point are bad, but you're not going to change his mind. So even if you were right all along, the outcome is that people are screwed because bcachefs is no longer maintained in the kernel. Every day, I ask myself, do I want to be right, or do I want to be effective?
        koverstreet 1y ago
        That attitude is how you get ahead as an individual at the expense of our whole field. That's how you end up with decisionmaking that's nothing more than popularity contests and no one even bothering to do the analysis on which option is technically better. That way leads the death of leadership. If you want to accomplish something as challenging as a filesystem, you do it by consistently making the right call and sticking to it, over and over and over. And if you keep doing that, eventually you end up with the most active filesystem community around, and the ability to flip even the kernel community the bird when their weaponized incompetence becomes too much :)
  - Voultapher 1y ago
    Don't hold your breath. I've approached Kent two weeks ago and offered to help upstream changes into the kernel so he wouldn't have to interact with any of the kernel people ... he claimed without being able to explain why that having a go-between couldn't possibly help and that if he couldn't dictate the kernel release schedule he wouldn't want to ship the software anyway. And then proceeded to dunk on btrfs.
    - yencabulator 1y ago
      Totally expecting to see bcacheos next. (Then maybe down the line people will realize Linus had a heart of gold behind his foul mouth.)
- johnisgood 1y ago
  Same. I liked many of its features (actually, all features, see https://bcachefs.org 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.
  - ThatPlayer 1y ago
    It's not unusable, I use it on a spare computer for fun, cuz I want tiering of SSD + HDDs. And this doesn't mean development has stopped, just not done in the kernel.
    - johnisgood 1y ago
      True, I did not mean to say usable, I meant to say that "officially supported", but I will give it a go with a custom built kernel sooner or later. For how long have you been using it? Any issues? Any favorite feature(s) in particular?
      - ThatPlayer 1y ago
        I've been using it about a year or so. Like I said, the 'killer feature' for me is tiering. I'm not using it on my main computer, but a spare parts computer with whatever storage I have laying around thrown into it, so being able to combine a 3TB HDD with a 1/2 TB SSD. All the storage stays usable, and I get better performance. Not perfect though. Performance at times doesn't seem better than just SSD, though I didn't really test that and I'm not sure if it's just hitting the HDD at those times. And there was a kernel version that didn't boot, though I'm staying on the bleeding edge with Arch Linux.
  - ahartmetz 1y ago
    What I expect to happen is that bcachefs stabilizes outside of mainline, and after that, it can be merged back because no large patches = not much drama potential.
    - 1y ago
bgwalter 1y ago
[deleted wrongthink]
- graemep 1y ago
  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.
  - teekert 1y ago
    Good addition,thanx. I've been in a similar situation, letting everyone know I was fired. Apparently in the US this has a negative connotation, and they use "being let go" (or something confusing as "handing in/being handed your 2 weeks notice", a concept completely unknown here). Here we only have one word for "your company terminating your employment", and there is no negative connotation associated with it. This can be difficult for non-natives. We can come across very weird or less intelligent.
    - T3OU-736 1y ago
      In the US, the terminology tends to split into "fired" (implies "for valid reasons") vs "laid off" (implies "position was terminsted, this was not about the employee or their qualities and performance").
      - graemep 1y ago
        In the UK "fired" would mean the same, "laid off" off would mean the same, "made redundant" also means the same and more clearly, with emphasis on the position no longer existing. "Sacked" means about the same as fired.
  - dbdr 1y ago
    Funnily enough the apology ends with: > If the above offended anyone, I sincerely apology them. Unless this was tongue-in-cheek, this kind of proves the point that language was the cause. The apology is a good move in any case.
motorest 1y ago
Ultimately that's the right call, and the inevitable one as well.
qalmakka 1y ago
RIP BCacheFS. I was hopeful I could finally have a modern filesystem in Linux mainlined (I don't trust Btrfs anymore), but I guess I'll keep on having to install ZFS for the foreseeable future I guess. As I predicted, out of tree bcachefs is basically dead on arrival - everybody interested is already on ZFS, btrfs is still around only because ZFS can't be mainlined basically
- Ygg2 1y ago
  Wait. You don't trust Btrfs but you would trust BCacheFS, that's obviously very experimental?
  - rurban 1y ago
    Still more stable than btrfs. btrfs is also dead slow
    - Iridiumkoivu 1y ago
      I agree with this sentiment. Btrfs has destroyed itself on my testing/lab machines three times during last two years up to point where recovery wasn’t possible. Metadata corruption being main issue (or that’s how it looks like to me at least). As of now I trust BCacheFS way more. I’ve given it roughly the same time to prove itself as Btrfs too. BCacheFS has issues but so far I’ve managed to resolve them without major data loss. Please note that I currently use ext4 in all ”really important” desktop/laptop installations and OpenZFS in my server. Performance being the main concern for desktop and reliability for server.
      - bcrl 1y ago
        ext4 has its own issues usually more in terms of scalability. XFS is trustworthy without the glass jaws ext4 has all over the place. Ah, the joy of taking 80 seconds to write out an 8MB file to disk after a fresh mount....
  - phire 1y ago
    Btrfs claims to be stable. IMO, it's not. It's generally fine if you stay on the happy path. It will work for 99% of people. But if you fall off that happy path, bad things might happen and nobody is surprised. In my personal experience, nobody associated with the project seems to trust a btrfs filesystem that fell off the happy path, and they strongly recommend you delete it and start from scratch. I was horrified to discover that they don't trust fsck to actually fix a btrfs filesystem into a canonical state. BCacheFS had the massive advantage that it knew it was experimental and embraced it. It took measures to keep data integrity despite the chaos, generally seems to be a better design and has a more trustworthy fsck. It's not that I'd trust BCacheFS, it's still not quite there (even ignoring project management issues). But my trust for Btrfs is just so much lower.
the_duke 1y ago
This is a tragedy, bcachefs has so many great features...
rurban 1y ago
> Once the BCacheFS maintainer behaves and the code is maintained upstream again, we will re-enable... (As IMO, it is a useful feature.) How cynical. It's the kernel maintainer, not the bcachefs maintainer, who does not behave and has a huge history of unprofessional behavior for decades.
- happymellon 1y ago
  The bcachefs maintainer has added new features during bugfix windows, and lied about it.
  - pantalaimon 1y ago
    It's still an experimental module, the feature was about gathering more debug information.
    - yjftsjthsd-h 1y ago
      If it's an experimental module, then it can surely wait for the next release; after all, nobody should be relying on code that's explicitly marked experimental.
    - StopDisinfo910 1y ago
      So? Bug fix windows are for bug fix. If it’s not a bug fix, it goes in the next version. That’s how the kernel release cycle works. It’s not very complicated. If it’s so unstable that it urgently needs new features shipped regularly, I think it’s entirely legitimate that it has to live out of tree until it’s actually stable enough.
- nicman23 1y ago
  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.
- boricj 1y ago
  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@suse.cz/ https://lwn.net/ml/all/bece61a0-b818-4d59-b340-860e94080f0d@...
jtickle 1y ago
All of the "btrfs eats your data" bugs have been fixed and the people who constantly repeat them are people who relied on an experimental filesystem for files they cared not to lose. FUD all around. 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. Since then I have used it in plenty of production environments. Don't do RAID 5. Just don't. That's not just a btrfs shortcoming. I lost a hardware RAID 5 due to "puncture" which would have been fascinating to learn about if it hadn't happened to a production database. It's an academically interesting concept but it is too dangerous especially with how large drives are now, if you're buying three, buy four instead. RAID 10 is much safer especially for software RAID. Stop parroting lies about btrfs. Since it became marked stable, it has been a reliable, trustworthy, performant filesystem. But as much as I trust it I also have backups because if you love your data, it's your own fault if you don't back it up and regularly verify the backups.
- arccy 1y ago
  "performant", it's still slow if you actually use any of the advanced features like copy on write.
  - FirmwareBurner 1y ago
    Every CoW filesystem is just as slow. There's no magic pill to fix performance but it's a known tradeoff.
    - koverstreet 1y ago
      Not inherently. Early bcachefs was ridiculously fast, it's gotten slower as we've grown all the features to compete with ZFS. All the database stuff that gives us amazing flexibility adds overhead (the btree iterator code has gotten fat), backpointers and modern accounting blew up our journalling overhead. A lot things that we needed for scalability, or hardening/self healing, have added overhead. COW really isn't the main thing, it's cramming all the features in that we want these days while keeping the fastpaths fast that's the tricky part. But, a lot of this stuff is fixable - performance just hasn't been the priority, since the actual users aren't complaining about performance and are instead clamoring for things like erasure coding. (and, the performance numbers that I've seen comparing us to ZFS still put us _significantly faster)
M95D 1y ago
I'm still waiting for an overlayfs that does read caching on the overlay without the need to format the backing storage.
- rekoil 1y ago
  Sounds like what bcache does? https://bcache.evilpiepirate.org/ https://bcache.evilpiepirate.org/ This is what bcachefs is based on.
  - M95D 1y ago
    From kernel Documentation/bcache.txt: > You'll need make-bcache from the bcache-tools repository. Both the cache device and backing device must be formatted before use. So, it's far from overlayfs. I could accept formatting the cache device, but not the backing storage.
- duffyjp 1y ago
  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.
betaby 1y ago
Very theoretical question. If there was a usable microkernel, how hard would be it be to have an FS as a service? Are MacOS FS' processes or are they 'monolithic'?
- yjftsjthsd-h 1y ago
  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.
  - betaby 1y ago
    I'm aware of FUSE and used NTFS driver though it back then. So we should expect similar performance with microkernels?
    - yjftsjthsd-h 1y ago
      It depends:) Old microkernels infamously did have awful perf because they took that context switch hit on everything, not just filesystems. I am told, though, that that was solved a long time ago and modern microkernels have fairly good performance. I'm not a kernel dev, though; you'll have to do your own research to get details.
- xenadu02 1y ago
  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.
zoezoezoezoe 1y ago
dodged a bullet with this one. Migrated away from BCacheFS on my openSUSE deployments a few days ago because I could see the writing on the wall for a while.

70 points by 6581 1y ago

lupusreal 1y ago

The way the BCacheFS situation has been playing out is a tragedy. I had very high hopes for it.

InsideOutSanta 1y ago
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.
- johnisgood 1y ago
  > Once the BCacheFS maintainer behaves [...] So, there are still behavioral issues here I take it? That is a bummer. This is not news to me, but I thought the situation has changed ever since.
  - motorest 1y ago
    > So, there are still behavioral issues here I take it? From the past discussion, it's mainly grave behavioral issues but they also end up being technical. Such as trying to push new untested features into RCs and breaking builds, and resorting to flame wars to push these problematic patches forward instead of actually working them out with maintainers. But yeah, the final straw was a very abusive email sent to a maintainer in the mailing list.
    - koverstreet 1y ago
      ...Where are you getting this stuff? Seriously, every time I read tales about all the horrific things I've done in the kernel community, the stories grow and get wilder and wilder. Oh wait. It's you.
      - johnisgood 1y ago
        That is just people for you. My advice would be to not let them prompt you to leave such comments because it will appear to confirm what they are saying.
        koverstreet 1y ago
        In my experience, the trolls never go away unless you start poking at them to point out how ridiculous and laughable they are.
      - InsideOutSanta 1y ago
        One thing I've learned over 40 years of working in software development is that it is often more effective to collaborate productively with others than to be right. Maybe Linus's rules for what can be merged at what point are bad, but you're not going to change his mind. So even if you were right all along, the outcome is that people are screwed because bcachefs is no longer maintained in the kernel. Every day, I ask myself, do I want to be right, or do I want to be effective?
        koverstreet 1y ago
        That attitude is how you get ahead as an individual at the expense of our whole field. That's how you end up with decisionmaking that's nothing more than popularity contests and no one even bothering to do the analysis on which option is technically better. That way leads the death of leadership. If you want to accomplish something as challenging as a filesystem, you do it by consistently making the right call and sticking to it, over and over and over. And if you keep doing that, eventually you end up with the most active filesystem community around, and the ability to flip even the kernel community the bird when their weaponized incompetence becomes too much :)
- Voultapher 1y ago
  Don't hold your breath. I've approached Kent two weeks ago and offered to help upstream changes into the kernel so he wouldn't have to interact with any of the kernel people ... he claimed without being able to explain why that having a go-between couldn't possibly help and that if he couldn't dictate the kernel release schedule he wouldn't want to ship the software anyway. And then proceeded to dunk on btrfs.
  - yencabulator 1y ago
    Totally expecting to see bcacheos next. (Then maybe down the line people will realize Linus had a heart of gold behind his foul mouth.)
johnisgood 1y ago
Same. I liked many of its features (actually, all features, see https://bcachefs.org 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.
- ThatPlayer 1y ago
  It's not unusable, I use it on a spare computer for fun, cuz I want tiering of SSD + HDDs. And this doesn't mean development has stopped, just not done in the kernel.
  - johnisgood 1y ago
    True, I did not mean to say usable, I meant to say that "officially supported", but I will give it a go with a custom built kernel sooner or later. For how long have you been using it? Any issues? Any favorite feature(s) in particular?
    - ThatPlayer 1y ago
      I've been using it about a year or so. Like I said, the 'killer feature' for me is tiering. I'm not using it on my main computer, but a spare parts computer with whatever storage I have laying around thrown into it, so being able to combine a 3TB HDD with a 1/2 TB SSD. All the storage stays usable, and I get better performance. Not perfect though. Performance at times doesn't seem better than just SSD, though I didn't really test that and I'm not sure if it's just hitting the HDD at those times. And there was a kernel version that didn't boot, though I'm staying on the bleeding edge with Arch Linux.
- ahartmetz 1y ago
  What I expect to happen is that bcachefs stabilizes outside of mainline, and after that, it can be merged back because no large patches = not much drama potential.
  - 1y ago

bgwalter 1y ago

[deleted wrongthink]

graemep 1y ago
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.
- teekert 1y ago
  Good addition,thanx. I've been in a similar situation, letting everyone know I was fired. Apparently in the US this has a negative connotation, and they use "being let go" (or something confusing as "handing in/being handed your 2 weeks notice", a concept completely unknown here). Here we only have one word for "your company terminating your employment", and there is no negative connotation associated with it. This can be difficult for non-natives. We can come across very weird or less intelligent.
  - T3OU-736 1y ago
    In the US, the terminology tends to split into "fired" (implies "for valid reasons") vs "laid off" (implies "position was terminsted, this was not about the employee or their qualities and performance").
    - graemep 1y ago
      In the UK "fired" would mean the same, "laid off" off would mean the same, "made redundant" also means the same and more clearly, with emphasis on the position no longer existing. "Sacked" means about the same as fired.
- dbdr 1y ago
  Funnily enough the apology ends with: > If the above offended anyone, I sincerely apology them. Unless this was tongue-in-cheek, this kind of proves the point that language was the cause. The apology is a good move in any case.

motorest 1y ago

Ultimately that's the right call, and the inevitable one as well.

qalmakka 1y ago

RIP BCacheFS. I was hopeful I could finally have a modern filesystem in Linux mainlined (I don't trust Btrfs anymore), but I guess I'll keep on having to install ZFS for the foreseeable future I guess. As I predicted, out of tree bcachefs is basically dead on arrival - everybody interested is already on ZFS, btrfs is still around only because ZFS can't be mainlined basically

Ygg2 1y ago
Wait. You don't trust Btrfs but you would trust BCacheFS, that's obviously very experimental?
- rurban 1y ago
  Still more stable than btrfs. btrfs is also dead slow
  - Iridiumkoivu 1y ago
    I agree with this sentiment. Btrfs has destroyed itself on my testing/lab machines three times during last two years up to point where recovery wasn’t possible. Metadata corruption being main issue (or that’s how it looks like to me at least). As of now I trust BCacheFS way more. I’ve given it roughly the same time to prove itself as Btrfs too. BCacheFS has issues but so far I’ve managed to resolve them without major data loss. Please note that I currently use ext4 in all ”really important” desktop/laptop installations and OpenZFS in my server. Performance being the main concern for desktop and reliability for server.
    - bcrl 1y ago
      ext4 has its own issues usually more in terms of scalability. XFS is trustworthy without the glass jaws ext4 has all over the place. Ah, the joy of taking 80 seconds to write out an 8MB file to disk after a fresh mount....
- phire 1y ago
  Btrfs claims to be stable. IMO, it's not. It's generally fine if you stay on the happy path. It will work for 99% of people. But if you fall off that happy path, bad things might happen and nobody is surprised. In my personal experience, nobody associated with the project seems to trust a btrfs filesystem that fell off the happy path, and they strongly recommend you delete it and start from scratch. I was horrified to discover that they don't trust fsck to actually fix a btrfs filesystem into a canonical state. BCacheFS had the massive advantage that it knew it was experimental and embraced it. It took measures to keep data integrity despite the chaos, generally seems to be a better design and has a more trustworthy fsck. It's not that I'd trust BCacheFS, it's still not quite there (even ignoring project management issues). But my trust for Btrfs is just so much lower.

the_duke 1y ago

This is a tragedy, bcachefs has so many great features...

rurban 1y ago

> Once the BCacheFS maintainer behaves and the code is maintained upstream again, we will re-enable... (As IMO, it is a useful feature.) How cynical. It's the kernel maintainer, not the bcachefs maintainer, who does not behave and has a huge history of unprofessional behavior for decades.

happymellon 1y ago
The bcachefs maintainer has added new features during bugfix windows, and lied about it.
- pantalaimon 1y ago
  It's still an experimental module, the feature was about gathering more debug information.
  - yjftsjthsd-h 1y ago
    If it's an experimental module, then it can surely wait for the next release; after all, nobody should be relying on code that's explicitly marked experimental.
  - StopDisinfo910 1y ago
    So? Bug fix windows are for bug fix. If it’s not a bug fix, it goes in the next version. That’s how the kernel release cycle works. It’s not very complicated. If it’s so unstable that it urgently needs new features shipped regularly, I think it’s entirely legitimate that it has to live out of tree until it’s actually stable enough.
nicman23 1y ago
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.
boricj 1y ago
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@suse.cz/ https://lwn.net/ml/all/bece61a0-b818-4d59-b340-860e94080f0d@...

jtickle 1y ago

All of the "btrfs eats your data" bugs have been fixed and the people who constantly repeat them are people who relied on an experimental filesystem for files they cared not to lose. FUD all around. 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. Since then I have used it in plenty of production environments. Don't do RAID 5. Just don't. That's not just a btrfs shortcoming. I lost a hardware RAID 5 due to "puncture" which would have been fascinating to learn about if it hadn't happened to a production database. It's an academically interesting concept but it is too dangerous especially with how large drives are now, if you're buying three, buy four instead. RAID 10 is much safer especially for software RAID. Stop parroting lies about btrfs. Since it became marked stable, it has been a reliable, trustworthy, performant filesystem. But as much as I trust it I also have backups because if you love your data, it's your own fault if you don't back it up and regularly verify the backups.

arccy 1y ago
"performant", it's still slow if you actually use any of the advanced features like copy on write.
- FirmwareBurner 1y ago
  Every CoW filesystem is just as slow. There's no magic pill to fix performance but it's a known tradeoff.
  - koverstreet 1y ago
    Not inherently. Early bcachefs was ridiculously fast, it's gotten slower as we've grown all the features to compete with ZFS. All the database stuff that gives us amazing flexibility adds overhead (the btree iterator code has gotten fat), backpointers and modern accounting blew up our journalling overhead. A lot things that we needed for scalability, or hardening/self healing, have added overhead. COW really isn't the main thing, it's cramming all the features in that we want these days while keeping the fastpaths fast that's the tricky part. But, a lot of this stuff is fixable - performance just hasn't been the priority, since the actual users aren't complaining about performance and are instead clamoring for things like erasure coding. (and, the performance numbers that I've seen comparing us to ZFS still put us _significantly faster)

M95D 1y ago

I'm still waiting for an overlayfs that does read caching on the overlay without the need to format the backing storage.

rekoil 1y ago
Sounds like what bcache does? https://bcache.evilpiepirate.org/ https://bcache.evilpiepirate.org/ This is what bcachefs is based on.
- M95D 1y ago
  From kernel Documentation/bcache.txt: > You'll need make-bcache from the bcache-tools repository. Both the cache device and backing device must be formatted before use. So, it's far from overlayfs. I could accept formatting the cache device, but not the backing storage.
duffyjp 1y ago
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.

betaby 1y ago

Very theoretical question. If there was a usable microkernel, how hard would be it be to have an FS as a service? Are MacOS FS' processes or are they 'monolithic'?

yjftsjthsd-h 1y ago
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.
- betaby 1y ago
  I'm aware of FUSE and used NTFS driver though it back then. So we should expect similar performance with microkernels?
  - yjftsjthsd-h 1y ago
    It depends:) Old microkernels infamously did have awful perf because they took that context switch hit on everything, not just filesystems. I am told, though, that that was solved a long time ago and modern microkernels have fairly good performance. I'm not a kernel dev, though; you'll have to do your own research to get details.
xenadu02 1y ago
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.

zoezoezoezoe 1y ago

dodged a bullet with this one. Migrated away from BCacheFS on my openSUSE deployments a few days ago because I could see the writing on the wall for a while.