I think this was the right thing

Posted Sep 30, 2025 20:53 UTC (Tue) by koverstreet (✭ supporter ✭, #4296)
In reply to: I think this was the right thing by roryi
Parent article: Bcachefs removed from the mainline kernel

I think you've got this entirely backwards.

A good fraction of the bcachefs users are using it because they've been burned and lost entire filesystems on btrfs, and needed something more reliable - they've found bcachefs to be that.

"Meme filesystem"? Seriously? I'm just trying to get users a modern filesystem that's actually bulletproof - and succeeding, aside from upstream drama.

I think this was the right thing

Posted Oct 1, 2025 1:03 UTC (Wed) by ebiederm (subscriber, #35028) [Link] (17 responses)

You have a mode where you simply do not comprehend what other people say to you. That mode causes problems when interacting with other people.

I hope this split from the mainstream kernel takes some of the pressure off and allows you to make progress.

I think this was the right thing

Posted Oct 1, 2025 3:09 UTC (Wed) by buck (subscriber, #55985) [Link] (9 responses)

I don't think anything in Mr. Overstreet's comment warranted the ad-hominem reply. He merely proposed that happy bcachefs users were not generally there because they were swept up by the latest fad but had instead found something they calculated was a better guarantor of their data availability and integrity than the alternatives, as a counterpoint to supposing anybody using bcachefs was unserious. In taking up for his users, i don't see any hint of bad faith or disparagement of anything else, except for the oblique implication that there are filesystems that some users consider less reliable than his but not even hinting which they might be.

(Note: I am not a bcachefs user. I may also be unserious, but not this time.)

I think this was the right thing

Posted Oct 1, 2025 8:00 UTC (Wed) by Nikratio (subscriber, #71966) [Link] (1 responses)

With "the oblique implication that there are filesystems that some users consider less reliable than his but not even hinting which they might be", do you mean "they've been burned and lost entire filesystems on btrfs"?

If you look at other communication, you'll find that Kent is generally unable to discuss something without immediately disparaging other developers, filesystems, or packagers.

I think this was the right thing

Posted Oct 14, 2025 11:13 UTC (Tue) by taladar (subscriber, #68407) [Link]

Having read many of the discussions on this bcachefs issue here on LWN I have only ever seen Kent be professional while many others seemed to personally attack him.

I think this was the right thing

Posted Oct 1, 2025 11:01 UTC (Wed) by josh (subscriber, #17465) [Link] (4 responses)

> warranted the ad-hominem

"ad-hominem" does not apply to the comment you're responding to. It applies when you dismiss someone's argument not because it's false but because of some unrelated property of themselves. It doesn't describe comments on someone's personal issues that are not being used to dismiss someone's arguments. In particular, ad-hominem doesn't typically apply to meta-commentary on someone's argumentative style and raising issues with it. "X is obnoxious behavior that makes it really annoying to try to talk to you" is not typically ad-hominem.

For instance (two entirely made-up examples with intentionally zero subtext):

"Your argument is incorrect because your shirt is wrinkled and therefore you are insufficiently fastidious to be taken seriously about this" is an ad-hominem.

"You have a habit of wringing your shirt with your hands, perhaps because you're nervous, which leads you to go on stage with a wrinkled shirt, and you might want to work on that" is not an ad-hominem. Note in particular that it is not attacking someone's argument by making an unrelated personal observation; it's telling someone that there's a problem they have that is affecting how they come across to others, and suggesting that they fix it.

I think this was the right thing

Posted Oct 2, 2025 2:23 UTC (Thu) by buck (subscriber, #55985) [Link] (3 responses)

I bow to your mastery of rhetoric.

I was not classically educated and was being a rube, trying to sling some Latin, trying to avoid saying, "personal", but turns out i made a more offensive accusation.

Sorry

Still seems to me some folks were overreacting to Mr. Overstreet's one comment that had been posted (as of the time i wrote anyway), which, prima facie, did not seem like a dig at anybody or their work. Is there some rationale for not addressing his comment on the merits? Maybe i'm just being obtuse, sorry

I think this was the right thing

Posted Oct 2, 2025 11:00 UTC (Thu) by ferringb (subscriber, #20752) [Link] (2 responses)

> Still seems to me some folks were overreacting to Mr. Overstreet's one comment that had been posted (as of the time i wrote anyway), which, prima facie, did not seem like a dig at anybody or their work. Is there some rationale for not addressing his comment on the merits? Maybe i'm just being obtuse, sorry

An example of the context you're missing is https://lwn.net/Articles/1035736/ . That includes examples of what you think folks should do, and kernel folk commentary it's long since been doing. LKML ain't exactly the nicest place, for them to level a CoC, let alone someone's entire project being ejected from the kernel, this isn't something that is because of a one off.

When you're going through that thread, I suggest you pay attention to the harassment of the debian dev (*again*). That's deeply unacceptable, and I suspect overstreet- in a year from now after this latest incident- will hope that there isn't someone doing exactly what he's been doing to others.

I think this was the right thing

Posted Oct 2, 2025 12:54 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (1 responses)

Oh boy.

> An example of the context you're missing is https://lwn.net/Articles/1035736/ . That includes examples of what you think folks should do, and kernel folk commentary it's long since been doing. LKML ain't exactly the nicest place, for them to level a CoC, let alone someone's entire project being ejected from the kernel, this isn't something that is because of a one off.

Others have noted that incident was on the whole rather tame, even for what passes on LKML today (I'm reading the news on Phoronix right now, and - oh boy, the level of toxicity really hasn't changed) - and that screwup had pretty far reaching consequences.

And re: Debian, I was talking about issues bcachefs has had with release process, and you're somehow painting that as harassment?

That's pretty unbelievable.

Look, I think the actual harassment going on here is pretty clear, and it crowds out all the actual technical discussions we could be having.

I think this was the right thing

Posted Oct 2, 2025 23:36 UTC (Thu) by ferringb (subscriber, #20752) [Link]

I just want to point out the blatantly obvious here; you're arguing against my advice that people just read your damn posts and interactions. OP asked why people respond this way, why they don't engage in your arguments; that thread demonstrates why there is the communal pattern.

If you don't think people should read your flamewars to understand the interaction, don't flamewar.

> And re: Debian, I was talking about issues bcachefs has had with release process, and you're somehow painting that as harassment?
> That's pretty unbelievable.

https://lwn.net/Articles/1035890/ (people should read it in full). Also your general justification for taking unrelated, deeply pointless and technically unproductive, potshots/attacks: https://lwn.net/Articles/1035878/

> I think the actual harassment going on here is pretty clear,

Few things that harassment isn't:
* People disagreeing with your posts and behavior within a community, and engaging you disagreeing.
* Linking your own posts were you are attacking others
* Suggesting people read your thread interactions and make up their own damn mind (in particular, reading in full rather than just the 2 examples I gave as a synopsis).

This is a good stopping point; as I said, folks should just read https://lwn.net/Articles/1035736/ .

I think this was the right thing

Posted Oct 3, 2025 4:22 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> He merely proposed that...

Imagine A and B are debating question X together.

C is around. He overhears and misunderstands a small bit, which reminds of topic Y. He joins A and B and "merely proposes" Y for 2 minutes.

But the connection between topic X and Y is tenuous and topic Y is of interest to neither A nor B. By sheer "coincidence", topic Y also allows C to brag a fair bit and to disparage some stuff done by others for some bonus points.

This sort of situation is not unusual, especially after a few drinks. I bet most people have seen it at least once.

But now, imagine C does this sober and in many of his social interactions. Like a "mode"?

PS: it becomes even more fun when it snowballs with D, E and F overhearing incomplete and different parts of Y and joining the (lack of) "conversation". Now this is almost comedy material. Or drama - often closer to each other than we think.

Here too, please stop

Posted Oct 3, 2025 4:30 UTC (Fri) by jake (editor, #205) [Link]

[ also not aimed at marcH only ]

This sub-thread lost whatever value it once had, can we please just let it rest?

thanks,

jake

I think this was the right thing

Posted Oct 1, 2025 10:48 UTC (Wed) by paulj (subscriber, #341) [Link] (6 responses)

I've besought Kent to stop posting a few times. He just can't help himself it seems. He appears to be unable to promote bcachefs without throwing digs (subtle and not so subtle) at other kernel developers. He seems unaware that he is doing this, or else of the effect of this style of communication.

Please Kent... just don't talk about other kernel subsystems, other people's kernel code (inc. kernel code generally). And... given you struggle with not pushing down on others (directly or indirectly)... just stay off forums. Please.

I think this was the right thing

Posted Oct 2, 2025 6:25 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (2 responses)

It's not happening :)

I think this was the right thing

Posted Oct 2, 2025 23:15 UTC (Thu) by neggles (subscriber, #153254) [Link] (1 responses)

As in, you're not going to stop posting/responding to bait in comment/ML threads? that doesn't really seem like something to be proud of, especially considering the resulting harm to bcachefs and its users

Imagine how much more development work you could get done if you didn't waste time "talking shit" (for lack of a better phrase)

I think this was the right thing

Posted Oct 3, 2025 0:18 UTC (Fri) by koverstreet (✭ supporter ✭, #4296) [Link]

On a subject as heated as... nearly everything bcachefs has been lately, there's often no firm line between 'bait' and legitimate discussions.

You can wish that all the offtopic, trollish stuff would just go away (and believe me I do), but ignoring it won't make it so. Ignoring it would only work if we had heavy handed moderators that could take that on, and I don't think we want that either.

And like I said, there's generally no real firm line between 'bait' and legitimate discussion, so you'd be leaving aside a lot of potentially productive discussion.

People talk a lot about abstract 'harm' these days too, and I don't see any actual justification for that.

Anyways, I took the prior comment as a wish that I would just stop appearing in public and do nothing but write code for everyone else to use. And to that I say - hell no :)

I think this was the right thing

Posted Oct 7, 2025 16:16 UTC (Tue) by nye (subscriber, #51576) [Link] (2 responses)

> I've besought Kent to stop posting a few times. He just can't help himself it seems

FWIW I've considered muting you for your frequent, typically baseless, and often unpleasant personal attacks, mostly against Kent. It's clear that you personally hate him for some reason; I think this is clouding your judgement.

> just stay off forums. Please

Indeed...

I think this was the right thing

Posted Oct 7, 2025 16:26 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

It's the opposite. I want Kent to succeed in making bcachefs a really good, modern, stable, self-integrity-checking FS available in Linux.

https://lwn.net/Articles/1027605/
https://lwn.net/Articles/1036511/
https://lwn.net/Articles/1036170/

I think this was the right thing

Posted Oct 7, 2025 19:08 UTC (Tue) by koverstreet (✭ supporter ✭, #4296) [Link]

Well, just dial back on the unsolicited advice, then :)

Whenever there's chaos and drama, everyone sizes on that and assumes the sky is falling and shows up with all sorts of funny, very instantly worded "advise".

It makes it hard to bring the focus back to productive technical conversations, where it needs to be.

Trust me, I'm the one writing you all a better filesystem, and I've got this :)

Now that kernel community and Linus drama are behind us, things are operating much more smoothly. Usage jumped up with the announcement of DKMS packages; some new bug reports but nothing serious.

We should still be on track for lifting the experiment label by the end of the year, and I'm enjoying nice quite days of just getting work done.

Lately that's been a big codebase reorg (súbdirs!) so new people can find their way around, and rebalance_v2 is nearly done.

Good stuff is coming, be patient :)

I think this was the right thing

Posted Oct 1, 2025 4:23 UTC (Wed) by rolexhamster (guest, #158445) [Link] (18 responses)

A good fraction of the bcachefs users are using it because they've been burned and lost entire filesystems on btrfs, and needed something more reliable - they've found bcachefs to be that.

It's easy to state the above, but the usual "citation needed" caveat applies.

Is there evidence to concretely state that, right now, btrfs (as of linux kernel 6.17) is less stable / more fragile than bcachefs (as of the DKMS version today) ?

This isn't about the historical (in)stability of btrfs at its development stage compared to (in)stability of bcachefs at the equivalent point in its development stage. This is also not about differences in feature sets.

This is about how things stand right now, as in is btrfs or bcachefs more reliable today, for plain non-fancy desktop usage.

(Disclaimer: I don't use btrfs or bcachefs. All my systems are on ext4, mainly due to inertia).

I think this was the right thing

Posted Oct 1, 2025 5:02 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Apparently people still don't trust btrfs's own advanced RAID modes: https://btrfs.readthedocs.io/en/latest/Status.html I absolutely got burned by it when booting degraded arrays and trying to reassemble them.

Another thing, btrfs support for multi-device setups is still not great, while bcachefs shines there. It's possible to configure complex cache hierarchies, so that most data is stored on fast SSDs and only periodically migrated to slower HDDs: https://bcachefs.org/Caching/

I think this was the right thing

Posted Oct 1, 2025 10:12 UTC (Wed) by gdamjan (subscriber, #33634) [Link]

meanwhile, bcachefs didn't mount a single device filesystem when kernel version (and bcachefs version) changed. luckily it wasn't the root device but an auxiliary one.

I do like to see the bcachefs project succeed, but its glory seems to me to be greatly exaggerated.

I think this was the right thing

Posted Oct 1, 2025 10:21 UTC (Wed) by ferringb (subscriber, #20752) [Link]

> Apparently people still don't trust btrfs's own advanced RAID modes: https://btrfs.readthedocs.io/en/latest/Status.html I absolutely got burned by it when booting degraded arrays and trying to reassemble them.

I hope you're not referring to raid5/6... which should frankly be behind CONFIG_BTRFS_EXPERIMENTAL since it is *just* for experimental/development use. The design lacks protections against the write hole problem, something upstream has tried to inform people of but seems to frequently get ignored. Quoting:

---
The RAID56 feature provides striping and parity over several devices, same as the traditional RAID5/6. There are some implementation and design deficiencies that make it unreliable for some corner cases and the feature should not be used in production, only for evaluation or testing. The power failure safety for metadata with RAID56 is not 100%.
---

The duplication functionality (raid1/c2, c3, etc) works fine and is what people use.

I think this was the right thing

Posted Oct 2, 2025 6:34 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (14 responses)

> Is there evidence to concretely state that, right now, btrfs (as of linux kernel 6.17) is less stable / more fragile than bcachefs (as of the DKMS version today) ?

The first thing to be aware of is that we don't have the kind of hard numbers on filesystem reliability that we'd like, no one does. For determining if a filesystem is 99.9%, 99.99%, etc. reliable - you'd really need telemetry.

So we have to go off of anecdotal data.

All that does in fact point to that:

- yes, btrfs does indeed still have reliability problems, and no one seems to know how to debug them

- bcachefs has been shaping up _fast_, and I think the userbase is big enough that I can conclusively say it's less fragile than btrfs. We simply haven't been seeing unrecoverable issues at any stage of development - barring ~1 or 2 extreme outliers that were solved quickly - and we seem to be pretty well past stability issues in general.

I think this was the right thing

Posted Oct 2, 2025 15:07 UTC (Thu) by rolexhamster (guest, #158445) [Link] (13 responses)

So we have to go off of anecdotal data.

Okay, where? As in what specific bug reports on, say, kernel bugzilla or LMKL.

All that does in fact point to that: ...

Anecdotes are not reliable facts, though to give you the benefit of the doubt, the above may have been an unfortunate or unintended choice of words.

At the same time, one cannot rely on anecdotes to say that btrfs is in worse/better shape than bcachefs. Relying on anecdotes to make an argument sounds more like FUD.

... I can conclusively say [bcachefs is] less fragile than btrfs.

How, quantitatively? Going off vibes is not the same as actually measuring the number of corruptions, crashes, failed recoveries, etc. There needs to be a concerted side-by-side comparison (such as stress testing, deliberate random corruption, etc), similar to what Backblaze does with hard drive reliability measurements.

Back when development of bcachefs started (as in ~10 years ago), there were a lot of lingering questions on the reliability of btrfs. At that point in time, these questions were a fair motivation for aiming to create a better file system. However, since then btrfs has improved and now has the advantage of being stabilised (except RAID5/6) for a far longer time period than bcachefs.

I think this was the right thing

Posted Oct 2, 2025 15:16 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (12 responses)

Look, if you're trying to argue btrfs is fit for purpose, you're smoking something.

https://news.ycombinator.com/item?id=45432749
https://news.ycombinator.com/item?id=45428033
https://news.ycombinator.com/item?id=45429813

This is just from the most recent hacker news filesystem thread where btrfs came up, which took me about 5 minutes. If I spent an afternoon I could find you hundreds of user reports like this.

I think this was the right thing

Posted Oct 2, 2025 15:33 UTC (Thu) by paulj (subscriber, #341) [Link] (7 responses)

One of the first posts on that yc story, from someone who has long sponsored you apparently, has this:

> From a long time (and now former) sponsor: if these posts are actually from you, please stop.

If btrfs sucks and has many issues, users and others will notice. As a dev of a filesystem in a similar space, you should of course take note and learn what you can from those issues. But... is it really helping you to be out there posting in various forums about how bad btrfs is and how much better your fs is?

I think this was the right thing

Posted Oct 2, 2025 16:22 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (6 responses)

> If btrfs sucks and has many issues, users and others will notice. As a dev of a filesystem in a similar space, you should of course take note and learn what you can from those issues. But... is it really helping you to be out there posting in various forums about how bad btrfs is and how much better your fs is?

Excuse me? Follow the thread back to see where this started: bcachefs was called a "meme filesystem", and I was just explaining that there's a real demand for something better than btrfs.

_Every single time there's a bcachefs thread_ this happens. I start out explaining "yes, btrfs really does have issues, bcachefs really is delivering something better" and then people coming out swinging accusing me of attacking btrfs.

You're just trolling.

Let's stop here

Posted Oct 2, 2025 16:26 UTC (Thu) by jake (editor, #205) [Link] (1 responses)

[ Not directed at Kent only, by any means ]

This sub-thread does not seem to be going anywhere useful for anyone. Can we please stop it here?

thanks,

jake

Let's stop here

Posted Oct 2, 2025 17:06 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link]

Thanks Jake, I appreciate it.

I think this was the right thing

Posted Oct 3, 2025 2:47 UTC (Fri) by interalia (subscriber, #26615) [Link] (3 responses)

> bcachefs was called a "meme filesystem"

I just want to say that that wasn't how I read it in context and I think you may have overreacted. The subthread was started by DemiMarie:

> I don’t think that experimental filesystems belong upstream. [snip] The need to get fixes out super quickly to recover user’s data does not mix well with the upstream kernel’s release cycle.

In reply, roryi said:

> It was very clearly marked as being experimental, though. I find it hard to understand who could possibly be using an experimental filesystem in a bleeding-edge kernel for important data without backups. [snipped]

> Has someone been actively recommending use of bcachefs to naive end users? Is there such a thing as a meme filesystem - and if so, has bcachefs somehow become one? Is there a rogue forum poster / youtuber / tiktoker out there tricking people into such risky behaviour without realising the implications?

I understood this reply to DemiMarie to be saying: "bcachefs was okay being upstream, because it was clearly marked as experimental. I would normally expect anyone using a filesystem marked as such in the most recent kernels would only be using it with backups, or with expendable data."

I don't think roryi was asserting that bcachefs IS a meme filesystem. In response to DemiMarie talking about data recovery they were asking if numerous users had somehow used a newer experimental filesystem without precautions, and IF so asking how they came to do so, finally asking speculatively if use of a new experimental filesystem somehow became a social media thing and thus encourage inexperienced users to do so. I thought it was a slightly odd thing to ask but I didn't consider it to be denigrating bcachefs's actual technical quality, so the entire subthread after that became an overreaction.

I think this was the right thing

Posted Oct 3, 2025 3:29 UTC (Fri) by koverstreet (✭ supporter ✭, #4296) [Link] (2 responses)

Well, if you'd like my take on who was actually using it: serious users, who were doing their homework first, would often come by the IRC channel (or Reddit) and ask if it was ready for use.

Up until recently (~6 months ago?), it seemed I was perpetually telling the people who sounded less risk averse to "check back in six months"; this included people who had been bit by recent data loss on btrfs even when we'd hit the point where similar data loss was going to be unlikely on bcachefs (that's never been much of a concern on bcachefs, although we used to have a lot of "downtime event" bugs, until those were worked through).

There have been a few people who clearly ignored the experimental label and jumped in much too early and ended up unhappy and disgruntled, but - the people who ended up the most disgruntled are also the ones who like to tout their storage industry experience, so can't say I feel much for those guys :)

Generally speaking it's been a lot of younger hobbyists/tinkerers, or older people with spare machines who know exactly why we need this and have been investing significant amounts of time QAing and beating on it.

And for all the people I can talk because I've been interacting with, I should also mention there's a much larger userbase who hasn't been pushing all the various features quite as hard for whom it's been working just fine.

So there's a good mix. Some people are legitimately using bcachefs in production - less critical or less demanding scenarios - some are testing the limits, some people are putting it onto any old junk and running real workloads (!).

Especially in the last six months, it's gotten sufficiently solid that the "people running it on random junk with real production workloads crown" have been coming up with all kinds of stories of it quietly and happily humming along through dying hardware and god knows what else that people seem fairly confident would have rather upset btrfs or even ZFS.

So I don't think there's any reason for people to be taking special precautions at this point. The only special precaution you ever needed to take was "if it wedges itself, be patient and feed us logs/metadata dump so we can get you bugfixes", and even that's pretty much stopped and the bugs have become pretty mundane.

I think this was the right thing

Posted Oct 3, 2025 4:18 UTC (Fri) by interalia (subscriber, #26615) [Link] (1 responses)

That's fine and all Kent, but I didn't ask about bcache's current users and maturity.

Rather than diverting my post into discussion of that, I'd be more interested in an acknowledgement that you might have misinterpreted what roryi said, or reasons why you think your interpretation was indeed correct if there was further context or subtext I didn't see.

Please, stop

Posted Oct 3, 2025 4:25 UTC (Fri) by jake (editor, #205) [Link]

[ again, this is not only aimed at interalia ]

This sub-thread is really not going anywhere very useful for anyone.

Please end it here.

thanks,

jake

I think this was the right thing

Posted Oct 2, 2025 15:47 UTC (Thu) by rolexhamster (guest, #158445) [Link] (1 responses)

if you're trying to argue btrfs is fit for purpose, you're smoking something.

Really Ken? The above response is quite disrespectful and dismissive.

My aim here is to have an intelligent (and polite) conversation about various potential merits/demerits of btrfs and bcachefs. As I've stated before, I don't use either btrfs or bcachefs, so all the questions and observations I have made are coming from a 3rd party point of view.

I think this was the right thing

Posted Oct 2, 2025 16:17 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link]

Why not do me the courtesy of getting my name right?

I think this was the right thing

Posted Oct 7, 2025 0:03 UTC (Tue) by Kamilion (guest, #42576) [Link] (1 responses)

Uh.... why do I see zero references to btrfs-recovery in any of these?

They're great anecdotes, but my realworld experience has been that most other filesystems have no recovery tools at all.
And I don't mean, "fix the filesystem", I mean, "other catastrophic failure occurred."

I've had a *lot* of spindles die, and have always been able to ask btrfs to drop the disk out of the array *before* any further problems occurred.

What other filesystem can even *do* that safely?

As far as I know, the only recovery tools for ext2/3/4, xfs, and the microsoft filesystems, other than testdisk, are commercial software.
Those hacker news posts are full of doing very silly things which will also break most recovery tools. Tossing md in the mix makes it nearly unrecoverable. lvm metadata loss has eaten more arrays than I can count in the field, which is why we ditched it a decade ago. Tradeins and RMAs went down significantly afterwards.

So far, I have *never* encountered an operational spindle that btrfs-recover could not extract customer data from.

*everything fails*. Having a path for recovery after failure is priceless. btrfs gigablocks are such a simple concept writ large that contribute to that path's viability.

XFS's correctness tests are quite nice and all, but if the on-disk structures present a problem to recover from without mounting, it's a major issue for deployments hosting unique data.

For every list of people having problems you can search up in 5 minutes, there's another batch of us who have found it reliable, and we are largely silent, busy doing our workloads.

I think this was the right thing

Posted Oct 14, 2025 11:25 UTC (Tue) by taladar (subscriber, #68407) [Link]

Most filesystems "can't" drop a disk out of an array before a problem occurs because RAID is completely out of scope for them, that is what mdraid or hardware RAIDs or LVM are used to solve with those.