Announcement

Collapse
No announcement yet.

Bcachefs Linux File-System Seeing Performance Improvements, Other Progress

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

  • #51
    Originally posted by pal666 View Post
    the bad thing happens when average imbecile thinks that others don't have such intents
    Do we need to babysit imbeciles now? When you start a project you state the goals, if someone is too dumb to comprehend them it's not your issue.

    That said I'd rather see imbeciles get scammed by a software project that has some chances of going anywhere even if small than a pyramid scheme about essential oils or some shit.

    i.e. all you can come up with against btrfs is raid56?
    No little shit, that's not what I said.

    I actually read the original goals and I clearly remember things like fully free redundancy levels (aka no "raid1/raid10/raid5/6" modes with fixed parity/striping/mirroring settings), combined mirror and stripes in the same array (not on the same drives), and more.

    But they grossly underestimated the complexity of the striping mode, so that part got more or less shelved for years and even now it's lackluster.

    Now, you want something against btrfs?

    Here, ages later we are still locked to RAID1, RAID0 and RAID10 that isn't particularly good performance-wise, while the performance with VMs and databases is complete trash unless you disable half its features with nocow.

    If the fucking array loses a drive, it has no concept of "degraded" and will just write in "single" mode (i.e. braindead mode on the first device it finds) so when you replace the drive you also need to run a full balance to check for all such "single" writes and fix them. Normal RAID systems will write in degraded mode, aka new writes are still done in the original RAID type, so that only the data on the dead drive must be resynced when you replace it.

    If I reboot the system with a degraded array it will FUCKING REFUSE TO MOUNT IT (no other RAID system does this), if it was your root filesystem and you don't have a paper with the commands to ask it to mount in degraded mode handy you are fucked until you can google it.

    Meanwhile, there are commercial KVM hypervisor distributions like Proxmox that literally use ZFS by default for the VM array, someone added support for ZFS pools in libvirt (kvm management libraries), and performance is actually very decent even without a SSD cache drive. On an array that is still Cow, mind me. And ZFS has none of the bullshit I mentioned above.
    Last edited by starshipeleven; 07-01-2020, 10:21 AM.

    Comment


    • #52
      Originally posted by lyamc View Post
      This is really interesting.
      Either I believe JustinTurdeau or starshipeleven and think that btrfs has never had any issues with anyone ever and it's only ever used error.
      or you learn to read instead of listening to voices in your head. they didn't say never. many years ago there were issues with btrfs. with bcachefs that buggy state is in far future
      Originally posted by lyamc View Post
      Now, I see the argument that it could be a big related to firmware. If all the other filesystem work without corrupting data, but needs corrupts data, then it's not the fault of the firmware.
      who told you that? if firmware doesn't implement some command according to spec, it's the fault of firmware, regardless of what effect it has on random filesystem
      Originally posted by lyamc View Post
      btrfs? Back in 2013
      only very stupid person will use 2013 version of btrfs in 2020. for comparison, current bcachefs is like btrfs 2007.

      Comment


      • #53
        Originally posted by starshipeleven View Post
        Do we need to babysit imbeciles now?
        well, this thread is full of them
        Originally posted by starshipeleven View Post
        When you start a project you state the goals, if someone is too dumb to comprehend them it's not your issue.
        "not eating data" is among goals of any fs. it's like "holds files and directories".
        Originally posted by starshipeleven View Post
        I actually read the original goals and I clearly remember things like fully free redundancy levels (aka no "raid1/raid10/raid5/6" modes with fixed parity/striping/mirroring settings), combined mirror and stripes in the same array (not on the same drives), and more.
        it has Features Currently in Development or Planned for Future Implementationlist on wiki and it contains Object-level mirroring and striping.
        Originally posted by starshipeleven View Post
        But they grossly underestimated the complexity of the striping mode, so that part got more or less shelved for years and even now it's lackluster.
        that part isn't shelved, raid1 and raid0 work perfectly. and if it's so hard, it will be even harder for guy on donations
        Originally posted by starshipeleven View Post
        the performance with VMs and databases is complete trash unless you disable half its features with nocow.
        there's no way around it and no other cow filesystem will be fast. vms and databases can snapshot themselves.
        Originally posted by starshipeleven View Post
        ZFS
        has obsolete design, doesn't exist on linux and can't change size, useless

        Comment


        • #54
          Originally posted by pal666 View Post
          if i double all his claims, will you pay me?
          if you have something working which looks like that it can fullfill them: maybe

          Comment


          • #55
            Originally posted by nomadewolf View Post
            The difference being, BTRFS is supposedly in 'ready', and bcachefs isn't even mainlined yet...
            there's no difference btw. nobody mainlined btrfs in knowingly bad shape. it had no bugs in testing on its author machine. but with each order of magnitude more users new bugs were uncovered. same fate awaits any filesystem. also bugs can be introduced by future development. again, no filesystem is invulnerable to it

            Comment


            • #56
              Originally posted by flower View Post
              if you have something working which looks like that it can fullfill them: maybe
              are you qualified to judge it? nevemind, i'll start with bcachefs fork. so i have bcachefs current and claim double of all his claims. ready to pay?

              Comment


              • #57
                Originally posted by duby229 View Post
                Everything has a beginning, so had btrfs at one point in time as well....
                sure, but bcachefs is a decade late and has order of magnitude less manpower. so in about one century it will reach current btrfs state

                Comment


                • #58
                  Originally posted by pal666 View Post
                  "not eating data" is among goals of any fs. it's like "holds files and directories".
                  It's still not a wrong goal.

                  it has Features Currently in Development or Planned for Future Implementationlist on wiki and it contains Object-level mirroring and striping.
                  No it is not in development. I'm subscribed to btrfs mailing list, I know what is happening and this isn't even on the radar.

                  that part isn't shelved, raid1 and raid0 work perfectly.
                  RAID1 is mirroring, and the striping of RAID0 is much much simpler of what you need for RAID5/6. In RAID5/6 there is striped parity too, in RAID0 there is no such thing.

                  there's no way around it and no other cow filesystem will be fast.
                  So is ZFS "not a CoW filesystem" now? ZFS has better performance because it has better caching, another feature Btrfs currently lacks.

                  vms and databases can snapshot themselves.
                  Yes but only databases are CoW, and I would love to use filesystem-level compression on a VM array.

                  has obsolete design,
                  maybe, but it has like a decade of head start so it's still much better.
                  doesn't exist on linux
                  it's available for installation in all major distros. Guess why.
                  and can't change size, useless
                  You mean shrinking? It can surely increase size, that's good enough for most workloads.

                  Yes ZFS is less flexible but it has much better performance and can actually do more, I'd say that's a fair tradeoff.
                  Last edited by starshipeleven; 07-01-2020, 11:15 AM.

                  Comment


                  • #59
                    Originally posted by pal666 View Post

                    are you even a programmer? did you look at sources?
                    I'd rather not go into excessive details. As USD is nearing its crashing point ans Israel is desperately working on finishing its graft onto "Fourth Reich" that is to rise as New EU, there is flood of personal attacks on forums, meant to acquire "fingerprint" of various visitors, sometimes with help of staff on site ( acquiring IP, sometimes injecting malitious scripts that use timing attack to sniff out keys on the maxchien etc)

                    This post fis nicely in the pattern. You waited some time, so that article falls below its peak of attention, so your risk is minimal and still get desired information...


                    Comment


                    • #60
                      Originally posted by Brane215 View Post
                      I'd rather not go into excessive details. As USD is nearing its crashing point ans Israel is desperately working on finishing its graft onto "Fourth Reich" that is to rise as New EU, there is flood of personal attacks on forums, meant to acquire "fingerprint" of various visitors, sometimes with help of staff on site ( acquiring IP, sometimes injecting malitious scripts that use timing attack to sniff out keys on the maxchien etc)

                      This post fis nicely in the pattern. You waited some time, so that article falls below its peak of attention, so your risk is minimal and still get desired information...

                      Comment

                      Working...
                      X