Announcement

Collapse
No announcement yet.

XFS Online Repair Functionality To Undergo A Massive Design Review

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

  • XFS Online Repair Functionality To Undergo A Massive Design Review

    Phoronix: XFS Online Repair Functionality To Undergo A Massive Design Review

    The XFS file-system updates have been submitted and merged for the ongoing Linux 5.18 merge window...

    https://www.phoronix.com/scan.php?pa...18-XFS-Changes

  • #2
    I am quite biased towards BTRFS, but this is really interesting news. I have not looked much into XFS in recent years, and I assume that the online repair is only for metadata, but it is still a step in the right direction. Last thing I heard was that XFS was working on copy on write and subvolumes , but I assume that bad data can not be detected (no checksums??) - is this still true?

    http://www.dirtcellar.net

    Comment


    • #3
      XFSv5 has CRCs (see mkfs.xfs / xfs_info). CoW is done (cp --reflink a b).
      Code:
      # xfs_info /
      meta-data=/dev/mapper/cr-auto-1 isize=512 agcount=16, agsize=7806160 blks
      = sectsz=512 attr=2, projid32bit=1
      = crc=1 finobt=1, sparse=1, rmapbt=0
      = reflink=1 bigtime=0 inobtcount=0

      Comment


      • #4
        Code:
        crc=value
        This is used to create a filesystem which maintains and checks CRC
        information in all metadata objects on disk. The value is either 0 to disable
        the feature, or 1 to enable the use of CRCs.
        Key word metadata. You still have to punt to the block layer if you want data integrity.

        Comment


        • #5
          Originally posted by splatterlight View Post
          Code:
          crc=value
          This is used to create a filesystem which maintains and checks CRC
          information in all metadata objects on disk. The value is either 0 to disable
          the feature, or 1 to enable the use of CRCs.
          Key word metadata. You still have to punt to the block layer if you want data integrity.
          As Linus once said, users care about their data, not metadata. There is no point in having great consistent metadata if the data themselves are corrupt.

          Comment


          • #6
            Originally posted by jacob View Post

            As Linus once said, users care about their data, not metadata. There is no point in having great consistent metadata if the data themselves are corrupt.
            Well if the data is stored on BTRFS backups and XFS is able to let you know what file(s) went toast then it might be a viable solution still.

            http://www.dirtcellar.net

            Comment


            • #7
              Originally posted by waxhead View Post

              Well if the data is stored on BTRFS backups and XFS is able to let you know what file(s) went toast then it might be a viable solution still.
              But it can't, that's the thing. XFS has no mechanism to detect data (file content) corruption. I don't see how it could even be implemented without data (not just metadata) COW.

              Comment


              • #8
                Originally posted by uxmkt View Post
                XFSv5 has CRCs (see mkfs.xfs / xfs_info). CoW is done (cp --reflink a b).
                Code:
                # xfs_info /
                meta-data=/dev/mapper/cr-auto-1 isize=512 agcount=16, agsize=7806160 blks
                = sectsz=512 attr=2, projid32bit=1
                = crc=1 finobt=1, sparse=1, rmapbt=0
                = reflink=1 bigtime=0 inobtcount=0
                Is there a way to make CoW the default behaviour for something like that, or is that a tools issue?

                Comment


                • #9
                  Originally posted by microcode View Post

                  Is there a way to make CoW the default behaviour for something like that, or is that a tools issue?
                  You can do an alias for cp to be cp --reflink=auto

                  Code:
                  alias cp='cp --reflink=auto --sparse=always'

                  Comment


                  • #10
                    Originally posted by microcode View Post
                    Is there a way to make CoW the default behaviour for something like that, or is that a tools issue?
                    The alias command should likely be alias cp='/bin/cp ..' just to avoid running into a recursion. Anyway, even btrfs does not auto-cow on cp, or does it? (TTBOMK it only does that when making a dedicated snapshot with e.g. `btrfs sub snap`.)

                    Comment

                    Working...
                    X