Announcement

Collapse
No announcement yet.

Approved: Fedora 33 Desktop Variants Defaulting To Btrfs File-System

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

  • Originally posted by 240Hz View Post
    The default for Fedora is XFS, a highly performant and stable filesystem. BTRFS is buggy and suffers from severe performance issues as can be seen in all XFS, EXT4 vs BTRFS benchmarks
    First of all BTRFS does quite a bit more than any of the other filesystems. With complexity you of course have more bugs, but what you rather should be concerned about is if any of these bugs leads to dataloss. And if the disaster hits , will you be able to confidently extract your data knowing that it is not corrupted.

    No filesystem is fault proof , therefore you need tested, working backups. That is no different from EXT4, XFS, BTRFS or whatever filesystem you want to throw into the mix. As for BTRFS you know if your data is is good or bad and RAID1,10 are well proven and fix just about any corruption you can throw at it.

    http://www.dirtcellar.net

    Comment


    • Originally posted by pal666 View Post
      education for zfs imbeciles https://lwn.net/Articles/342892/
      So by quoting that you want to say that you don't know that current btrfs design has only a little to do with what is now?😂

      Comment


      • Originally posted by kloczek View Post
        Maybe you should read that since then only new FS in Linux which is btrfs only have been tryint to mimic ZFS??
        btrfs doesn't try to mimic zfs. btrfs was written by reiserfs dev and reiserfs was already btree-based, cow btrees were invented by ibm dev soon after it and were incorporated into btrfs design. it shares some features with zfs because those are useful features, it doesn't share design at all, its design is far superior. and zfs wasn't first cow filesystem btw. you could educate yourself further with https://www.researchgate.net/publica...ree_filesystem
        (one of paper authors is fedora feature(subj) owner btw)
        Originally posted by kloczek View Post
        That try was only partial as long as long as it was not by design trying to archive any crucial goals which ZFS archived and by this btrfs underneath is usong tevhnologies which are so old as Linux themeselve ..
        moron, btrfs already reached many goals unreachable by zfs. and cow btrees were published in 2008(btrfs development started in 2007)
        Last edited by pal666; 16 July 2020, 03:07 PM.

        Comment


        • Originally posted by jacob View Post

          I hope so. I'm a mostly happy Ubuntu user but ZFS is a nonstarter for me.
          Why? It's fine if you want the features it provides.

          Don't tell me you believe "OMG it's illegal!" or something, because it's clearly not. Even if it was, the GPL doesn't apply to users.

          Comment


          • Originally posted by pal666 View Post
            btrfs doesn't try to mimic zfs. btrfs was written by reiserfs dev and reiserfs was already btree-based, cow btrees were invented by ibm dev soon after it and were incorporated into btrfs design. it shares some features with zfs because those are useful features, it doesn't share design at all, its design is far superior. and zfs wasn't first cow filesystem btw. you could educate yourself further with https://www.researchgate.net/publica...ree_filesystem
            moron, btrfs already reached many goals unreachable by zfs. and cow btrees were published in 2008(btrfs development started in 2007)
            The same thing is wrong with BTRFS that is wrong with most of Linux today.

            It's hackish and it has no core direction.

            I can give you an example in Linux containers. There is no such thing as a "Linux Container" in the kernel, it's an upstack abstraction based on namespace and cgroups, it was never designed and there is no primitive concept for it, it was just components hacked together that made the abstraction known as a container possible. If you look at how Sun did Zones or BSD did Jails you can see they were engineered from the ground up to be containers, they had a clear problem they were trying to solve and designed software to solve it. There are whitepapers published on their designs and concepts. Linux doesn't do this, Linux hacks together existing components and arrives at the end product. This is why Zones and BSD has jid (zoneid) in it's ps and Linux maps the "container" pid to some other pid. The pid mapping is a hack. BSD and Solaris went in and did the work to the kernel to understand the concept of nesting and then added the jid's and zoneid supports to ps, top and everything else in the OS. Linux never finished the work.

            BTRFS reuses and recycles a ton of things that were never designed to do what it is attempting to accomplish. if you want to have your data integrity based around that philosophy.. be my guest.

            You can look at it like food. A potluck evolves where are 7 course meal is designed. You can get pretty good potato salad from a potluck but nobody is going to bring roast lamb in mint sauce. Sometimes things need to be designed to be truly exceptional.
            Last edited by k1e0x; 16 July 2020, 03:33 PM.

            Comment


            • Originally posted by kloczek View Post
              So by quoting that you want to say that you don't know that current btrfs design has only a little to do with what is now?😂
              moron, you imagined redesign of btrfs between 2009 and now?
              here is nice comparison from 2013 paper
              While ZFS and BTRFS have a lot in common, they also differ substantially.
              • Goals: ZFS is intended for an enterprise class Solaris server, BTRFS is intended to run on (almost) all things running Linux.
              • Filesystem check fsck: ZFS does not have an fsck utility. If the RAID and checksum algorithms are insufficient, the ZFS user is expected to restore from external backup. By contrast, Linux is installed on many desktops, and smartphones, that do not have enterprise grade backups. Linux users have therefore come to expect fsck utilities. Unfortunately, writing a good recovery tool for BTRFS is very hard, as the data can move around on disk, and there is no fixed location for metadata (except for the superblock).
              • Blocks vs. extents: ZFS uses blocks that are powers of two: 4KB, 8KB, ..., 128KB. Each object has a fixed block-size. the RAID-Z code works well with fixed sized blocks, however, since there are several different block sizes, we could run out of a particular size. This requires a procedure called ganging where larger blocks are created from smaller blocks. Since there might not be contiguous sub-blocks, the system can very well get into trouble. On BTRFS, extents are used instead of blocks. This eliminates the need for special block sizes. However, if the system is left with a highly fragmented free space, writes to disk are still going to be inefficient.
              • Checksums: both ZFS and BTRFS calculate checksums. However, ZFS keeps them in the block-pointers, whereas BTRFS keeps data checksums in a separate tree. This is necessary for BTRFS, since extents could be very large, and we would like to be able to validate each page separately.
              • Snapshots vs. clones: ZFS uses birth-times to build snapshots. BTRFS uses the reference-counting mechanism instead. The result is very similar, however, the BTRFS mechanism is more general, in that it supports clones as first class citizens.
              • RAID: ZFS uses RAID-Z, and supports several RAID levels including single/dual parity (RAID {5, 6}). BTRFS uses something closer to a standard RAID layout; support is currently available only for mirroring, striping, and mirroring+striping (RAID levels {0, 1, 10}).
              • Back references: ZFS does not support back-references, while BTRFS does. ZFS is assumed to run in a big server with many disks, and it can be assumed that redundancy through RAID-Z is implemented. This means that ZFS can recover bad blocks through reconstruction, failing that, there is backup. BTRFS cannot assume underlying RAID and multiple devices, hence, it must be able to cope with bad blocks by other means.
              • Deduplication: ZFS supports deduplication, although this comes at a very significant memory cost. BTRFS does not support this feature at the moment. Due to the memory requirements, it might be a feature only fit for high end servers.
              since then btrfs added support for out-of-band dedup
              Last edited by pal666; 16 July 2020, 03:40 PM.

              Comment


              • Originally posted by pal666 View Post
                moron, you imagined redesign of btrfs between 2009 and now?
                here is nice comparison from 2013 paper

                since then btrfs added support for out-of-band dedup
                Could you please as well tell why in that compartion ZFS is so many times mentioned when it comes what has btrfs?
                Or what btrf offer which ZFS doesn't?? Maybe crappy commandline to manage btrfs?


                "Deduplication

                Data deduplication capabilities were added to the ZFS source repository at the end of October 2009,[54] and relevant OpenSolaris ZFS development packages have been available since December 3, 2009 (build 128)."

                Since btrfs has no such thing like ARC in which is possible to keep all hashes of the deduplicated blocks deduplication in btrfs is very limite causeing big IO overhead.
                You would know that if you would be using dedup on btrfs.

                Comment


                • Originally posted by k1e0x View Post
                  The same thing is wrong with BTRFS that is wrong with most of Linux today.

                  It's hackish and it has no core direction.
                  i only see something wrong with you
                  Originally posted by k1e0x View Post
                  I can give you an example in Linux containers. There is no such thing as a "Linux Container" in the kernel, it's an upstack abstraction based on namespace and cgroups, it was never designed and there is no primitive concept for it, it was just components hacked together that made the abstraction known as a container possible. If you look at how Sun did Zones or BSD did Jails you can see they were engineered from the ground up to be containers, they had a clear problem they were trying to solve and designed software to solve it
                  it's well-known fact. inferior oses come with rigid containers, linux comes with building blocks out of which you can build containers which will suit you and that allowed linux containers to dominate. this is why when you say "container" you mean "linux" rather than "bsd" or "sun"
                  Originally posted by k1e0x View Post
                  BTRFS reuses and recycles a ton of things that were never designed to do what it is attempting to accomplish.
                  you post random words without knowing their meaning

                  Comment


                  • Originally posted by pal666 View Post
                    moron, you imagined redesign of btrfs between 2009 and now?
                    here is nice comparison from 2013 paper

                    since then btrfs added support for out-of-band dedup
                    That's biased.

                    ZFS does not need fsck and having it would not help it do anything better. It has no journal to replay but does have the checksum it validates on each read. if it's wrong it will automatically repair (if another source exists)
                    blocks vs extents, this is all true. ZFS uses variable block sizes and a root to leaf tree. Both filesystems will suffer fragmentation issues at ~90% usage.
                    ZFS also supports clones and writable snapshots. BTRFS isn't unique here.
                    ZFS's deduplication is being rewritten to be ram friendly. The design for it is published using a log format instead of what it currently uses (a bitmap) When this is finished it will support ref-links and you will be able to dedup say, your /home (currently the dev's have been somewhat preoccupied with the changes to the repo of record based on Zol, but that is nearly finished now.)

                    Where it is true ZFS was designed for the enterprise and large storage. As we often find in computing what was once only available to supercomputers is, given time, in every smart phone. Storage data management of our personal systems is looking closer to what enterprise was using a few decades ago.
                    Last edited by k1e0x; 16 July 2020, 04:03 PM.

                    Comment


                    • Originally posted by pal666 View Post
                      i only see something wrong with you
                      [..]
                      you post random words without knowing their meaning
                      FYI I have nothing to do with subject so please fucus on the subject .. not on me.

                      Comment

                      Working...
                      X