Bcachefs Looks Like It Won't Make It For Linux 6.6

[WereCatf]

the issue with stuff like github and gitlab is that none of them are conducive to the long and branching threads discussions can take. and when you split discussions from code management that is it's own massive clusterfuck.

That's exactly why I said I'd want a separate platform for discussions; if the conversation isn't specifically about the submitted patch, it doesn't belong on Github/Gitlab/Gitea/whatever, but somewhere more conducive for sprawling conversations. I view it as a form of using the right tool for the job and trying to cram everything under e.g. Github, or mailing lists, isn't the right approach.

That said, I'm not trying to start a fight with anyone about this and this is just my opinion.

[Quackdoc]

That's exactly why I said I'd want a separate platform for discussions; if the conversation isn't specifically about the submitted patch, it doesn't belong on Github/Gitlab/Gitea/whatever, but somewhere more conducive for sprawling conversations. I view it as a form of using the right tool for the job and trying to cram everything under e.g. Github, or mailing lists, isn't the right approach.

That said, I'm not trying to start a fight with anyone about this and this is just my opinion.

we already have that for stuff like IRC or now I like zulip, but ideally uou do need to have support for long threads of discussion right with the code

[mdedetrich]

They're not using mailing lists as a communications system, though; they're using it both for communications and for patch management and submission.

As someone who has experience with both worlds, i.e. traditionally contributed to OS projects that use Github for everything and OS projects that use mailing lists for discussions and github for issues/code/vcs (i.e. ASF - Apache Software Foundation projects), I can safely say that mailing lists are just terrible for anything that is not legal record keeping, i.e. voting for releases (which some projects, i.e. ASF ones do).

Mailing lists are so crudely primitive that they are terrible for even basic communication in software projects and the only redeeming qualities of mailing lists is that they are not tied to a specific website/company (although with self hosted gitlab this is a non issue).

[Old Grouch]

1. I only talked about how people talk, the language is irrelevant for that, at least mostly, the point is to not ask for how they feel or how their holiday was or something like that, and not say "ohh and you did great but maybe you could do greater if you did not do everything wrong"... sugarcoding, that is about the direct thing.

2. we have to see that this languages are not only written languages but also spoken even in English this are 2 different languages if you know 1 you don't know the other, while with german there are hard rules with very little exceptions which let's you speak words you never heard by the gramatic rules completely correctly when you read it and if you hear them you can correctly write them.

While in english you have 20 different ways to write the exact same sounds.

3. compound words, make it easier to learn than learning a new word for everything, Luftballon seems a bit long for the english balloon, but with the hot air balloon suddenly has the air part in it, too. So it's even inconsistent. Sure we get a bit silly with it sometimes with Stinktier and Faultier und Stachelschwein and Meerschwein, which translates to:
Stinktier -> smelly animal -> Methitidae (a subpart and false friend would be the stink badgers, but still it's a badger not a "animal")
Stachelschwein -> spiked pig -> porkupine
Meerschweinchen -> little sea pig -> guinea pig

Besides the long words we need less words as you can see and we have way less problems learning how to write our language, the long words (not so often used in reality) might intimitate new learners, the real pain for foreigners is the gendering of languages, but that is not german specific most european languages besides english have that.

While with english I have to look up very often the writing of words, because it's just some random letters that are very different not ohh do I need a s or ss here or t or tt but a "pth" or "f", "th" vs "f" or "through" or "true" very similar sounding words written completely different (there are better examples just best I can think of in 5 seconds).

Oho! I would never say English is the perfect language, or that its spelling is easy. I believe it is reasonably true to say that English is easy to learn to speak simply (you don't have to worry about grammatical gender or whether things are nominative, accusative, dative, genitive, ablative, whatever - but English verb tenses and moods can get nastily complicated) - I think you can get away with a vocabulary of 800 word roots - but it takes a lifetime to learn how to speak (and write!) it well. English spelling is horribly inconsistent - it makes more sense if you know the history of what that came to be, but it has successfully resisted reforms by Webster and Shaw. There's no formal body that maintains a guide to correct English: it's basically what people agree it to be by usage, which is irritating to many people (including me), but it makes it very flexible. Once upon a time Latin was the lingua franca of the known world, now it is English, and it will be something else in the future. There was a time when the study of Chemistry demanded that you could read German, but that time has passed.

There is a stereotype in Britain that people from Yorkshire are blunt, which corresponds with the idea of directness and not sugar-coating stuff. The trouble is, many people do not respond well to bluntness, and sugar-coating works better - an often used phrase is 'politeness costs nothing' - so although direct, plain talking (think of Quakers, as well) ought to work well, it turns out that social lubrication can be important. If you want to participate in a system where people are more indirect, you need to learn how to do the same, or forever be an outsider. You can try to change the system, but that is hard and slow work, and rarely successful.

I sympathise very much when you say that sugar-coating ought to be unnecessary, but I'm afraid that for a lot of people it is.

If you are dealing with British English speakers, this guide which translates what they say into what they mean might help: Anglo-EU translation guide

(I forgot to add a well-known example of the insanity of English spelling and pronunciation. It is a joke difficult to render in other languages:
Q:How do you pronounce the word ghoti?
A: "Fish". gh as in rough, o as in women, and ti as in station.
If you would like to challenge yourself on English spelling and pronunciation, I recommend that you get a full copy of the poem entitled The Chaos by a Dutchman, Gerard Noist Trenité, (an Internet search will reveal many) and try reading to follow along while a good speaker of English reads it aloud. Note that very few will get it completely correct.)

[blackiwid]

I sympathise very much when you say that sugar-coating ought to be unnecessary, but I'm afraid that for a lot of people it is.

Well if I say I don't care about it, I mean that in both ways, if people get directly or indirectly paid that work in such environment you play that games, but it should not go on cost of information you need at this point.

So it's not like 30% sugarcoating can reduce information about 100% the necessary information must be always 100% the rest can be added if necessary.

Especially if you leave out information to manipulate somebody, it's much worse than being direct and skip sugar coating. Also funny enough that you have no special word for that in english but must use some term from the cooking process. We call it beschoenigen aka Benicening or something alike.

Usually because we use compound words it's the other way around I think. But yes if you only give partial information every step that is what I referred with passage paper A22 or what it was, and probably Kent called Kafka-esk.

People seem to be fixed on did Kent do something wrong, yes probably, but does that end all blame games or questions, or can it be that some of the kernel devs played him wrong, too. If yes, then it would be interesting in what way and then which actions are worse and what outcome is worse.

I think the problem is that if he get's blamed and nobody acknologing blame and tries to do better or commit do do better and maybe partially making it up to him by making him a offer to help him go through the steps. Then we all might long or never get his FS in the kernel. That is a loss to millions of linux users.

If he was mostly wrong and we help him despite him being mostly wrong, some people in the kernel devs are having such small egos that they feel betrayed or something and worst case quit, many if not all of them get in one way or another paid I would assume so just quiting seem not very likely to me.

So even if you say "well Kent you did mostly wrong, but we help you anyway" would be a better outcome in my view. But it seems that the system is so week that small erruptions can make it all collaps otherwise I can't explain such procedure.

And when I then analyse this email, and I have not a clear message like either: "it's not in linux-next so this time it will not be added" or "if you do X Y Z we will maybe/likely add it" I don't get much confidence that the leadership is blame free. Especially if it includes some acceptance of blame, I just wonder if that's all of it, because if that was the only bad thing that happend to Kent in alle communication with the Kernel Mailing list, I would wonder if he would use the Kafka term.

I hope he eventually sums up what his problem is or somebody reads all the communication and give a fair summary what things can be said negatively towards the people in the LKML about this process.

If really Kent was unreasonable without any reason and everybody else always answered completely his questions or requests timely and nobody did anything wrong but Kent.

[jacob]

But speaking of "power failures" and "system crashes", there are stories floating around, about how BTRFS is vulnerable to power failures and not safe to use without UPS battery or laptop battery. People used BTRFS, power interrupted, the system reboot and found the partition refuse to mount. They file system may still be repairable but it is causing a huge loss in availability. Then fanboys defended that BTRFS is just playing "better safe than sorry" when there are any tiny risk of data loss. But then you hear victims lost a lot of files after partition repair, because BTRFS think it can't guarentee the content of those files are 100% correct, thus should discard them even for any risk of just 1-bit of corruption. Then fanboys defended you should have done regular backups for important files already. We are playing "better safe than sorry" for any tiny risk of assuming corrupted file as authentic.

Hearing those stories make me fear BTRFS. It makes totally no sense for me for any filesystem to lose files it is not actually writing on right at the time of power interruption. And for self-proclaimed CoW filesystem, I rightfully expect it should give me back a version of intact files no matter what unfortunate timing the power interruption occurs.

Those are anecdotal stories that are worth as much as anyone else's. They make little sense on their own unless we know exactly what circumstances these failures occurred in: which kernel version (was it 15 years ago?), which btrfs features were in use, etc. In the absence of more specifics, it is probably safe to assume that failures happened when using RAID5/6 which has always been officially broken, but for some reason people still insist on using it at any cost even though they have been warned not to. FWIW, I completely lost a laptop partition not once but twice with ext4 and once with xfs. That doesn't mean those filesystems are worthless. Personally I would trust more SUSE and Fedora, who selected btrfs as their primary FS than some Joe Random on the internet.

[mdedetrich]

Those are anecdotal stories that are worth as much as anyone else's. They make little sense on their own unless we know exactly what circumstances these failures occurred in: which kernel version (was it 15 years ago?), which btrfs features were in use, etc. In the absence of more specifics, it is probably safe to assume that failures happened when using RAID5/6 which has always been officially broken, but for some reason people still insist on using it at any cost even though they have been warned not to. FWIW, I completely lost a laptop partition not once but twice with ext4 and once with xfs. That doesn't mean those filesystems are worthless.

Or we could just use ZFS which has a much higher bar of acceptance of features, i.e. they don't add anything until they know its working unlike btrfs 5/6 which was known not to work due to the disk layout when it was added.

Like we are dealing with filesystems here which can cause data loss, not random crashes for desktop programs which usually isn't a big deal.

Personally I would trust more SUSE and Fedora, who selected btrfs as their primary FS than some Joe Random on the internet.

Both SuSe (not sure if you are implying SuSe enterprise as well) and Fedora are desktop orientated filesystems and desktops typically have a trivial setup of btrfs which wouldn't expose the kinds of issues so such a statement also isn't demonstrating much.

Really there is only one configuration of btrfs that has been battle tested and known to be generally stable (which isn't some trivial single hd laptop setup), and thats RAID 10 and this is what facebook/oracle run btrfs on. If you run that config, your probably fine.

[jacob]

Or we could just use ZFS which has a much higher bar of acceptance of features, i.e. they don't add anything until they know its working unlike btrfs 5/6 which was known not to work due to the disk layout when it was added.

ZFS seems to be some sort of religion for some folks but no, it's not the universal answer. There are lots and I mean lots of things that don't work all that well with ZFS. Besides its licensing issues, it has design flaws that basically can't be fixed. It's not me saying it, it's ZFS developers. Deduplication, internal fragmentation and memory management are good examples.

Both SuSe (not sure if you are implying SuSe enterprise as well) and Fedora are desktop orientated filesystems and desktops typically have a trivial setup of btrfs which wouldn't expose the kinds of issues so such a statement also isn't demonstrating much.

The desktop use cases of btrfs are far from trivial. Again, the mindset seems to be that anything that is not a home NAS using RAID5/6 is "trivial" or irrelevant. In reality, the desktop settings use subvolumes and snapshotting (including writable snapshots especially with LXD), compression, space caching and more. They are far more likely than servers to use random writes, implying extent splitting and checksum recalculation, hard reboots, etc. When using virtualisation, the common and recommended setup is also to enable non-cow for the disk image files only. Basically all the advanced and nontrivial features of btrfs except RAID are exercised very heavily on desktops, in fact more so than in typical server workloads.

I'm not saying that btrfs doesn't have its problems, it certainly does, but so does ZFS, Ext4, XFS or NTFS. What I'm saying is that the horror stories about it are largely internet folklore that have little to do with actual facts. It's a robust, extremely reliable filesystem that has been used and tested in practice very extensively and works great, except in a single particular setup (RAID5) that has had "Warning! don't use this!" written all over it. But silly people insist that they absolutely must use precisely that because reasons, things break, and then they go and spill their hate on the internet.

[mdedetrich]

ZFS seems to be some sort of religion for some folks but no, it's not the universal answer. There are lots and I mean lots of things that don't work all that well with ZFS. Besides its licensing issues, it has design flaws that basically can't be fixed. It's not me saying it, it's ZFS developers. Deduplication, internal fragmentation and memory management are good examples.

These problems (which are overstated, and some of which are going to be solved i.e. de-duplication/memory management which are Linux specific integration issues, i.e. FreeBSD does not have them) are minor compared to actual data integrity/losing your data partition

The desktop use cases of btrfs are far from trivial. Again, the mindset seems to be that anything that is not a home NAS using RAID5/6 is "trivial" or irrelevant. In reality, the desktop settings use subvolumes and snapshotting (including writable snapshots especially with LXD), compression, space caching and more. They are far more likely than servers to use random writes, implying extent splitting and checksum recalculation, hard reboots, etc. When using virtualisation, the common and recommended setup is also to enable non-cow for the disk image files only. Basically all the advanced and nontrivial features of btrfs except RAID are exercised very heavily on desktops, in fact more so than in typical server workloads.

I'm not saying that btrfs doesn't have its problems, it certainly does, but so does ZFS, Ext4, XFS or NTFS. What I'm saying is that the horror stories about it are largely internet folklore that have little to do with actual facts. It's a robust, extremely reliable filesystem that has been used and tested in practice very extensively and works great, except in a single particular setup (RAID5) that has had "Warning! don't use this!" written all over it. But silly people insist that they absolutely must use precisely that because reasons, things break, and then they go and spill their hate on the internet.

Thats not my point, I am not talking about user usecases, I am saying that single hard disk BTRF's partitions is literally the easiest technical usecase for a CoW filesystem to handle because on a hardware level writes to a single drive can be atomic, thats not the case for multiple drives and hence BTRFS working on desktop is not really saying much.

[jacob]

Thats not my point, I am not talking about user usecases, I am saying that single hard disk BTRF's partitions is literally the easiest technical usecase for a CoW filesystem to handle because on a hardware level writes to a single drive can be atomic, thats not the case for multiple drives and hence BTRFS working on desktop is not really saying much.

Multi-disk is not particularly difficult compared to other features, and btrfs works just fine with it except in RAID5.