Announcement

Collapse
No announcement yet.

Google Is Exploring Potentially Using Btrfs In Android

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

  • #41
    Originally posted by kreijack View Post
    The checksum algorithms are different from the ones used in the RAID5/6. I.e. a checksum could be crc32 or md5 or sha...., instead the parity in raid5 is a simple xor between the blocks.
    Hm, then they must have crc32c acceleration for other reasons then, I know that everything from ancient Kirkwoods onwards have crc32c acceleration among with XOR acceleration and some encryption algorithm acceleration (usually AES).

    Comment


    • #42
      Originally posted by starshipeleven View Post
      Hm, then they must have crc32c acceleration for other reasons then,.
      parity = redundancy
      checksum = protect from corruption

      different tools for different jobs

      Comment


      • #43
        Originally posted by PuckPoltergeist View Post
        different tools for different jobs
        Yeah, I guessed that a checksumming algorithm would be used for that.
        I was wondering what is using crc32c enough in an embdded NAS running a ext4 mdadm raid to make sense to use space on the silicon for an accelerator. I thought mdadm would use it somehow like when scrubbing.
        Or is it for sata/ethernet? I thought it was done by the sat/ethernet controllers, not on CPU.

        It can't be ext4's metadata as on Kirkwoods the kernel was an ancient 2.something.

        Comment


        • #44
          Originally posted by starshipeleven View Post
          Yeah, I guessed that a checksumming algorithm would be used for that.
          I was wondering what is using crc32c enough in an embdded NAS running a ext4 mdadm raid to make sense to use space on the silicon for an accelerator. I thought mdadm would use it somehow like when scrubbing.
          Or is it for sata/ethernet? I thought it was done by the sat/ethernet controllers, not on CPU.

          It can't be ext4's metadata as on Kirkwoods the kernel was an ancient 2.something.
          Built on seven generations of the industry’s first, most scalable and widely adopted data infrastructure processors, Marvell’s OCTEON® 10, OCTEON® 10 Fusion and ARMADA® platforms, include a comprehensive range of in-line hardware accelerators and are optimized for AI cloud data centers, 5G wireless infrastructure, enterprise and wireline carrier networks.


          or short anwser: iSCSI

          Comment


          • #45
            Originally posted by pal666 View Post
            unlike you, they are not idiots
            Unlike you, i got an education from my parents and don't feel the need to insult people i don't know on the internet to make my points.

            Comment


            • #46
              Originally posted by Veto View Post
              Uhm, no! You failed to provide even a single argument why...
              Do i really need to?
              Ok. How about the fact that after all these years we still don't have reliable RAID?

              Also, here's an extract taken from https://www.patreon.com/bcachefs
              • btrfs, which was supposed to be Linux's next generation COW filesystem - Linux's answer to zfs. Unfortunately, too much code was written too quickly without focusing on getting the core design correct first, and now it has too many design mistakes baked into the on disk format and an enormous, messy codebase - bigger that xfs. It's taken far too long to stabilize as well - poisoning the well for future filesystems because too many people were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs multiple times and had to switch at the last minute, and server vendors who years ago hoped to one day roll out btrfs are now quietly migrating to xfs instead).
              Is anything here a lie?

              Comment


              • #47
                Some of the design problems in btrfs are summarized in a 2010 post by Edward Shishkin


                with follow-up comment and some statements by btrfs developer Chris Mason.

                My understanding is that they have been worked around in current btrfs code, without making any changes to the underlying design.

                Comment


                • #48
                  Originally posted by nomadewolf View Post

                  Do i really need to?
                  Ok. How about the fact that after all these years we still don't have reliable RAID?

                  Also, here's an extract taken from https://www.patreon.com/bcachefs
                  • btrfs, which was supposed to be Linux's next generation COW filesystem - Linux's answer to zfs. Unfortunately, too much code was written too quickly without focusing on getting the core design correct first, and now it has too many design mistakes baked into the on disk format and an enormous, messy codebase - bigger that xfs. It's taken far too long to stabilize as well - poisoning the well for future filesystems because too many people were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs multiple times and had to switch at the last minute, and server vendors who years ago hoped to one day roll out btrfs are now quietly migrating to xfs instead).
                  Is anything here a lie?
                  Impossible to say, if anything there is a lie, cause there is only the claim that it is wrong, but no explanation what is wrong (in detail) nor why this is wrong. Again I want to know what design mistakes are baked into the odf. I only read repetition of the claim. Bigger codebase than XFS? No surprise, does XFS has volume management? Far too long to stabilize? Did anybody compared how long XFS took to stabilize? Yeah I know, it was so stable from the first day, there wasn't even the need for some repair tool...

                  Comment


                  • #49
                    Originally posted by chithanh View Post
                    Some of the design problems in btrfs are summarized in a 2010 post by Edward Shishkin


                    with follow-up comment and some statements by btrfs developer Chris Mason.

                    My understanding is that they have been worked around in current btrfs code, without making any changes to the underlying design.
                    Need to recap the old discussion, but AFAIR there where some wrong assumptions by Edward. At least this wasn't a problem with the odf.

                    Comment


                    • #50
                      Why dont they use ZFS instead? It works on 512 MB systems such as Raspberry Pie:
                      Hi, I just setup ZFS 0.6.5.8 on my Raspberry Pi 3b with Raspbian 8 and have created a mirrored zpool with two external USB SSD disks of 500 GB each. While copying a lot of files from the network to...

                      Comment

                      Working...
                      X