Bcachefs Changes Rejected Reportedly Due To CoC, Kernel Future "Uncertain"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pmorph
    replied
    Originally posted by TheMightyBuzzard View Post
    I love people who jump into "Free as in speech" projects and immediately try to put their boots on the neck of speech. It's freaking hilarious, especially when they act like the morally superior ones. Tone troll to someone who doesn't know better, noob.
    If you have no respect for other peoples time (life), how do you expect them to care about your "free speech"?
    "Free as in speech" is the hardest community project of them all, without the will to co-operate it simply dies.

    Leave a comment:


  • clipcarl
    replied
    Originally posted by Panix View Post
    Agreed - so many ppl here supporting the CoC here is alarming. If KO is a jerk - it's their issue to deal with - publicly offering their dirty laundry is childish and demanding apologies and giving threats is juvenile and petty - they should just deal with it in-house. I think anyone including KO would eventually relent but they are being butt hurt about it so he is grumbling about the conflict - just settle it and move on - fix the damn code.
    I personally think that CoCs can and sometimes do provide a valuable tool that can contributes to the success of a software project. It is a well known and largely accepted fact that the behavior of certain individuals can be so off-putting that it causes others to not contribute.

    But you could also make the argument that the rules, implementation and enforcement of certain CoCs, such as in the case of the Linux kernel's CoC here, isn't as fair as it could be. If you did I wouldn't disagree with you.

    But the issue here isn't whether Kent or anyone else agrees with the CoC rules, it's Kent's seeming inability to follow any except those he wants to.

    To paraphrase someone wittier than I: We're trying to run a civilization here.

    Leave a comment:


  • TheMightyBuzzard
    replied
    Originally posted by ZeroPointEnergy View Post
    Do you project your political enemy on me that fits into your simpleton worldview molded by a byparty neo-liberal hypercapitalistic dystopia? Lol

    I don't have to be part of your moronic system to recognize the brain rot you people display in this discussions.

    A CoC gouverns how people interact in a project. People who can't take their ego back when interacting with others don't have a right to be heard. This is a software development projecf, not a public forum. Get some fucking perspective or fork off..
    Spout some more dipshit kid buzzwords they taught you in college to disguise the brainwashing they were doing.

    No, CoCs do nothing of the sort. That's simply the lie told to get it implemented. Then what it's really used for is drumming anyone you don't like out of the project while ignoring any amount of bad behavior of those who agree with you. Every. Single. Time.

    I love people who jump into "Free as in speech" projects and immediately try to put their boots on the neck of speech. It's freaking hilarious, especially when they act like the morally superior ones. Tone troll to someone who doesn't know better, noob.

    Leave a comment:


  • clipcarl
    replied
    Originally posted by mdedetrich View Post
    This is not what the issue is, obviously having backups is a good idea. What I am talking about is that if you have a ZFS partition on non ECC memory and someone reads from it and gets the data from memory, the chance of delivering bad data is significant enough to note. Usually people don't see these issues with non ECC memory because

    1. Data that is read from the filesystem without filesystems (i.e. non ZFS) is often done with zero copying so it doesn't go via RAM (which is where ECC matters)
    2. For the tasks where memory is used, it often sits in L2/L3 caches where moderm CPU's use error checking. For most tasks the memory gets cached into these caches due to how obscenely large they have gotten so you also don't have to deal with the problem

    The thing is with a filesystem, the amount of data we are talking about is so huge that by definition its non cachable and due to how RAM physically works, physically pushing huge amounts of data into RAM and reading off it at very high rates (and especially at overclocked/higher memory settings) greatly increases the risk of delivering bad data.
    This is nonsense. ZFS' use of the ARC is essentially no different than bcachefs' or any other filesystem's use of the page cache. The same theoretical chance of in-memory corruption due to faulty RAM, bad connections or cosmic rays applies to all of them.

    Leave a comment:


  • TheMightyBuzzard
    replied
    Originally posted by logical View Post

    Hate is definitely the key word here. It's amazing how so many relish, take pride in it, and boast about having it.
    You're confused? Good if surprising. Most of you idiots don't have the self-awareness or intellectual honesty to be confused. When faced with the majority repudiating everything you believe, most of you just double down and call everyone who hates you for your atrocious behavior and extremely destructive ideas *ists.

    Leave a comment:


  • clipcarl
    replied
    Originally posted by mdedetrich View Post
    Stop spreading horseshit, I have broken EXT4 so many times with hard power shutdowns, I had to deal with 4 broken machines recently at work where the filesystem corrupted itself.
    .
    Well, I don't know what to tell you. Your experience with XFS and EXT4 doesn't match mine either personally or professionally. Perhaps it's something you're doing wrong.

    Originally posted by mdedetrich View Post
    ...
    With CoW you can provide mathematically correct atomic operations over multiple physical block devices because CoW is only way to provide these guarantees while having zero trust the underlying hardware is working correctly.
    This is false. COW in and of itself doesn't provide any such guarantees. You could argue that a particular COW filesystem implementation (along with proper use of checksums) could provide such guarantees but it's not an intrinsic property of COW itself. BTRFS is a COW filesystem with checksumming but it quite infamously doesn't provide such guarantees in every multiple disk use-case.

    Your implication that COW is the only way a filesystem could provide such a guarantee is also false. A well-designed fully log-based filesystem could just as easily provide the same guarantee, for example. And I'm sure there are other approaches too.

    Originally posted by mdedetrich View Post
    Firstly I don't believe you (I think you are spreading shit) and secondly even if its true ...
    Then you must not read the bcachefs mailing list. I have reported several issues over the years. And no, I won't do your research for you and provide the links. Search for yourself. It is true, however, that I have never lost data due to bcachefs problems. But I've still had those problems and needed to build new filesystems and migrate my data over.

    Originally posted by mdedetrich View Post
    ... bcachefs is under active development with the experimental flag. That flag will only be removed once its proven that bcachefs can recover/heal from all situations which is currently being done ...
    If you actually believe that it's possible for a filesystem to to anticipate and recover from "all situations" then I've got a really valuable real-estate investment opportunity you may be interested in. Ironically, it's bcachefs' attempt to do this that caused my most recent issue where I had to rebuild a filesystem. (Again, read the mailing list.)

    Originally posted by mdedetrich View Post
    ... but whats undisputed is they[COW filesystems] are much safer than journalling filesystems.
    Well, that depends on how you choose to interpret the word "much" and what types of safety issues you choose to include and exclude in your evaluation. I've lost data in an enterprise environment on ZFS because it can develop pretty much unbounded potential tail latencies over time and for some workloads (in my case VMWare Enterprise on ZFS over NFS) that can trigger fatal errors and corrupted data.


    Originally posted by mdedetrich View Post
    Who is doing this? Your sprouting FUD.
    Disabling COW for VM images, databases and any other large files with lots of random writes due to massive performance issues is a very common recommendation on Linux. Just google "vm image nodatacow" or "database nodatacow" for lots of discussion of this.

    Originally posted by mdedetrich View Post
    Also wrong ZFS can be configured to only provide a success callback on a filesystem operation if the data is flushed to disk in the same way that postgres will only report an operation as successful if the data is flushed.
    I'm talking about non-synchronous writes which are the default for most operations.

    Originally posted by mdedetrich View Post
    Like I am sorry to break it to you but its kind of obvious you don't know what you are talking about.
    I strongly suspect that I have far more actual experience in this area than you. People who actually do this for a living (as I have) don't care so much about theory the way you do they care more about current real-life performance and reliability. It's one thing to say that bcachefs, BTRFS and ZFS should theoretically be more reliable than filesystems like XFS in some circumstances. It's another thing to suggest (as you seem to be) that they actually are more reliable overall. They're not. At least not currently.

    You're a bcachefs fan. It may be hard to tell from this conversation but I am too. But you need to be able to take a step back and look at things realistically. Bcachefs is not magic and not perfect. Nor is it the only possible way forward.
    Last edited by clipcarl; 22 November 2024, 05:11 PM.

    Leave a comment:


  • ZeroPointEnergy
    replied
    Originally posted by TheMightyBuzzard View Post
    Did you learn nothing a couple weeks ago? It's not just the alt-right that hates you. Not by a long, long way.
    Do you project your political enemy on me that fits into your simpleton worldview molded by a byparty neo-liberal hypercapitalistic dystopia? Lol

    I don't have to be part of your moronic system to recognize the brain rot you people display in this discussions.

    A CoC gouverns how people interact in a project. People who can't take their ego back when interacting with others don't have a right to be heard. This is a software development projecf, not a public forum. Get some fucking perspective or fork off..
    Last edited by ZeroPointEnergy; 22 November 2024, 04:37 PM.

    Leave a comment:


  • gotar
    replied
    Originally posted by clipcarl View Post
    No, I wasn't. I was talking about rejecting or accepting bcachefs for inclusion in the kernel which is what this entire discussion is about. Your mind-reading skills need more work.
    OK, let's check this once again then:

    Originally posted by clipcarl View Post
    The old Linus, before his kinder, gentler Linus 2.0 reboot, would have chewed Kent up and spit him out a long time ago and it would have been over before it got anywhere near this point.

    Leave a comment:


  • gotar
    replied
    Originally posted by Old Grouch View Post
    This is a good reason to question why 'consumer' hardware is almost exclusively non-ECC.
    To monetize - vide Xeon prices.

    Leave a comment:


  • gotar
    replied
    Originally posted by skeevy420 View Post
    Really? Any x86_64 CPU with 8GB of ram is too demanding of a setup?
    I wasn't clear enough (yeah, too lazy to write this before, I should have know...).

    By "demanding" I mean not only system itself (with 8 GB RAM you can only run some user-level system, try using it on bigger server), but also setup complexity.

    I have systems like:

    Code:
    $ lsblk | wc -l
    186
    [that's only active volumes and host-mounted btrfs subvolumes, there is more inactive (like snapshots) and guest-mounted]

    and to be honest doing this with ZFS is just too ...demanding.
    The OpenZFS docs are overwhelming - which is good, but demands time to read, understand, experiment and implement properly.

    Leave a comment:

Working...
X