Announcement

Collapse
No announcement yet.

XFS To Enjoy Big Scalability Boost With Linux 5.14

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

  • XFS To Enjoy Big Scalability Boost With Linux 5.14

    Phoronix: XFS To Enjoy Big Scalability Boost With Linux 5.14

    A big patch series out of Red Hat is now queued into the XFS file-system development Git branch that is part of the new material for the upcoming Linux 5.14 cycle...

    https://www.phoronix.com/scan.php?pa...alability-5.14

  • #2
    Does anyone know for which workloads XFS is especially suitable/viable in comparison to ext4?

    Comment


    • #3
      Originally posted by kiffmet View Post
      Does anyone know for which workloads XFS is especially suitable/viable in comparison to ext4?
      Funny you should ask. Michael periodically does filesystem benchmarks on various storage devices (i.e. the storage setup often changes from one set of benchmarks to the next).

      Here's one of the more recent ones. You can search for others.

      Last edited by coder; 12 June 2021, 06:30 PM.

      Comment


      • #4
        TYVM. After having seen the benchmarks I am temped to try it out.

        Comment


        • #5
          Originally posted by kiffmet View Post
          Does anyone know for which workloads XFS is especially suitable/viable in comparison to ext4?
          One unique feature I love is project quotas, aka limiting the size that a directory can take

          Comment


          • #6
            Originally posted by kiffmet View Post
            TYVM. After having seen the benchmarks I am temped to try it out.
            For general-purpose desktop-like workloads, I recommend choosing a filesystem based on features. I am a big fan of subvolumes, snapshots, and checksums, in BTRFS.

            Here's a comparison of filesystem features and capabilities:

            Comment


            • #7
              Originally posted by kbios View Post
              One unique feature I love is project quotas, aka limiting the size that a directory can take
              I wonder if BTRFS can have subvolume-specific quotas. That would give you a similar capability.

              Comment


              • #8
                Originally posted by coder View Post
                For general-purpose desktop-like workloads, I recommend choosing a filesystem based on features. I am a big fan of subvolumes, snapshots, and checksums, in BTRFS.

                Here's a comparison of filesystem features and capabilities:
                Those charts basically confirm my picking of ZFS due to its features.

                And it does quotas since that's the hot feature of the day.

                Comment


                • #9
                  On ext4 vs xfs, I have long since preferred xfs. Its adequately fast and doesn't leave lost+found directories around. However it cannot be shrunk.

                  Comment


                  • #10
                    Originally posted by kiffmet View Post
                    Does anyone know for which workloads XFS is especially suitable/viable in comparison to ext4?
                    It enables direct access to disk on block level through nfs4.1 IIRC, which is needed to fully utilize multipath mount.
                    Which means that there is no need to team or bond/team multiple NICs if client and server are connected to a switch through multiple NICs and exports and mounts are done right. Also no need for LACP-compatible switch.

                    But it seems it is a bit "fluffy" and slow with small files.
                    Bazillion small files seems to eat disk area more than with ext4.
                    But that might have been remedied to some degree recently.

                    If you have e.g. pNFS4.x server and it has say 6 disks in RAID6 and XFS filesystem and exporting shares from it through 2NICs,
                    cleint just gets a "map" from the server which file blocks are in which drive. Client can then issues requests to those drives through DoE (?) protocol directly to each drive in parallel fashion through available channels in parallel.
                    Last edited by Brane215; 12 June 2021, 10:09 PM.

                    Comment

                    Working...
                    X