Announcement

Collapse
No announcement yet.

Bcachefs Linux File-System Seeing Performance Improvements, Other Progress

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

  • #71
    Originally posted by starshipeleven View Post
    or on what they want you to see. Infiltrating fringe groups and spreading misinformation is a well-known staple of all secret police forces to keep dissidents busy and confused, or even "recruit" them unwillingly for their own cause..
    True, but people have acclimated to that - Intelligence treating information channel like a water stream. Once they get best access, they get clean water and then piss in the stream to poison it for ordinary folks.

    Krav Maga way- EVERYTHING can be an asset, obstacle or weapon. Governmental structure, social networks, information etcetc.


    That being said, it looks RF scanning equipment is here big time, with others to follow relatively shortly.
    Last edited by Brane215; 07-01-2020, 04:54 PM.

    Comment


    • #72
      Originally posted by Brane215 View Post
      I report on what I see around me.
      On a random forum thread on a completely unrelated topic. Take your meds schizo.

      Comment


      • #73
        Originally posted by starshipeleven View Post
        Since you are so cool, how do you "factor in the code" that a drive might just lie when you call a fsync? The kernel has no control over the drive internals, it can only send commands through an interface, and hope the drive controller obeys them.
        Design the whole thing accounting for worst possible cases? When you design something super-complicated with the naive assumption that nothing it depends on, would never somehow break - you are literally asking Murphy to kick your ass and collect your scalp.

        Comment


        • #74
          Originally posted by pal666 View Post
          i.e. it was used to mislead users and backers?
          No. Where did you get that notion?

          Originally posted by pal666 View Post
          what are you trying to imply, that every other filesystem has architecture and development model aimed to eat users data? that's same bullshit misleading users and backers. all filesystems have intention to not eat data. but people make mistakes from time to time. i.e. all bcachefs claims are load of bullshit
          I'm trying to imply that some filesystems are better architected and better designed than others. Kent claims that it's so for bcachefs. Whether you believe/trust this claim or not (or maybe you have proof for the contrary) is a different subject.
          Last edited by intelfx; 07-01-2020, 07:48 PM.

          Comment


          • #75
            Originally posted by JustinTurdeau View Post
            I have submitted code to the Linux kernel. It's barely any different than any other large scale project of that kind.
            The fact you don't realize this means there's a 99% likelihood that you're speaking as someone who's never submitted anything.
            It is, though. It's one of the very few large software projects that use Git and email rigorously.

            The fact that you don't realize this means there's a 99% likelihood that you lie... See, we both can play this game.

            Originally posted by JustinTurdeau View Post
            That is straight up incompetence, not some kind of honest mistake made while navigating the "procedural bureaucracy".
            He forgot to squash reverts and reword commit messages after rebasing. I don't see "incompetence". You can maybe argue that there's "incompetence" in using Git, but flawless proficiency in Git doesn't translate to proficiency in writing code, and vice versa.

            Comment


            • #76
              Originally posted by aht0 View Post
              Design the whole thing accounting for worst possible cases? When you design something super-complicated with the naive assumption that nothing it depends on, would never somehow break - you are literally asking Murphy to kick your ass and collect your scalp.
              If RAM bitflips and the filesystem silently writes out corrupt data, will you claim that the filesystem driver should have somehow protected itself against faulty RAM?

              The world doesn't work this way.

              When you design something super-complicated, you break it into layers with well-defined interfaces. When a layer doesn't follow its own interface (for example, when a disk drive completes a FUA command and then loses the data) you cannot guarantee anything.
              Last edited by intelfx; 07-01-2020, 07:55 PM.

              Comment


              • #77
                Originally posted by aht0 View Post
                Design the whole thing accounting for worst possible cases?
                That's not an answer

                You, the great programmer expert in filesystems, how do you deal with a drive that just lies when you call a fsync and returns "action completed" even if in fact it did not?

                There are no other commands to do a similar action, and no indication whatsoever that the data is on the platters/flash and not still in its own RAM cache, because you can at best interrogate the drive firmware, that will obviously report that it's all ok, but you cannot validate its statements.

                The only way is doing some indirect testing on boot or something and hope that the drive is blatantly lying (i.e. answers "action completed" immediately when it is unrealistic to be completed so fast). ANn if this indeed finds oddities you can just notify the user that his drives are trash, and good luck with that.

                Storage devices are black boxes, the only way they are supposed to work together is because they follow an API and some specifications. If they fail to do so and the feature is non-critical (say SSDs and some types of special async trim, don't remember the name atm), it can be blacklisted on OS side (Linux has extensive tables of blacklisted drives, all discovered empirically aka someone suffered data loss and did some investigation and testing to find out what went wrong) and never used. But if it is something basic and crucial like fsync is broken there is really no workaround, that drive is trash.

                Comment


                • #78
                  Originally posted by intelfx View Post
                  It is, though.
                  No, it's not.

                  Originally posted by intelfx View Post
                  See, we both can play this game.
                  You're the only one playing games.Have fun with that, brainlet.

                  Comment


                  • #79
                    Originally posted by JustinTurdeau View Post
                    You're the only one playing games.Have fun with that, brainlet.
                    You finally ran out of counterarguments and turned to petty insults?

                    Comment


                    • #80
                      Originally posted by useless View Post
                      Funny thing about that thread: the OP's hard drive is know to have very bad firmware revisions. Check https://lore.kernel.org/linux-btrfs/[email protected]. Sadly, btrfs depends on correct fsync behavior. Luckily, you can easily deal with them disabling the write cache.
                      OP's hard drive (Western Digital WD20EZRX) being one of "very bad firmware revisions) you linked against is at best questionable. He did not state it as
                      WDC WD20EZRX-00DC0B0 Firmware Version: 80.00A80
                      it could easily be some other model with differing firmware. Full string was not specified. Like WD20EZRX-00D8PB0

                      Originally posted by starshipeleven View Post
                      That's not an answer

                      You, the great programmer expert in filesystems, how do you deal with a drive that just lies when you call a fsync and returns "action completed" even if in fact it did not?
                      Childish ranting aside.

                      When machine happens to have "known problematic drive", btrfs driver should squirt regular warnings into system log and turn off write caching whether user likes it or not. That's what could be added to the code at minimum.

                      Originally posted by starshipeleven View Post
                      But if it is something basic and crucial like fsync is broken there is really no workaround, that drive is trash.
                      Particular series of drives is cheap low-end stuff but they tend to work within expected parameters on Windows. Ergo, problem is in Linux and/or it's file system. If other file systems can handle the drive, issue is hiding in the code of particular file system driver. End of logic chain.

                      I own one of these "listed problematic" 1Tb WD Greens. (WDC WD10EZRX). Work well enough as a "holding-stuff"-drive. In Windows. Maybe I should throw Tumbleweed on it and see what will happen.

                      Comment

                      Working...
                      X