Details

    • Bug
    • Resolution: Fixed
    • Major
    • Lustre 2.17.0
    • Lustre 2.16.0
    • None
    • 3
    • 9223372036854775807

    Description

      Here is the problem, Lustre does not filter supported attributes and as a result file became unaccessible.

      $touch /mnt/lustre/f2
      $lsattr /mnt/lustre/f2
      ---------------------- /mnt/lustre/f2
      $chattr +aAcCdDeFijmPsStTux /mnt/lustre/f2
      $lsattr /mnt/lustre/f2
      lsattr: No data available While reading flags on /mnt/lustre/f2
      $cat /mnt/lustre/f2
      cat: /mnt/lustre/f2: No data available
      $statx /mnt/lustre/f2
        File: /mnt/lustre/f2
        Size: 0         	Blocks: 0          IO Block: 4194304 regular empty file
      Device: 2c54f966h/743766374d	Inode: 144115205272502274  Links: 1
      Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
      Context: unconfined_u:object_r:unlabeled_t:s0
      Access: 2023-02-16 18:08:06.000000000 -0500
      Modify: 2023-02-16 18:08:06.000000000 -0500
      Change: 2023-02-16 18:08:06.000000000 -0500
       Birth: 2023-02-16 18:08:06.000000000 -0500
      

      Attachments

        Activity

          [LU-16569] chattr makes file unavailable
          pjones Peter Jones added a comment -

          Merged for 2.17

          pjones Peter Jones added a comment - Merged for 2.17
          gerrit Gerrit Updater added a comment -

          "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/58693/
          Subject: LU-16569 llite: fix file attribute operation
          Project: fs/lustre-release
          Branch: master
          Current Patch Set:
          Commit: 101b67fcd91617590006c8d16d74401f6489cf8d

          gerrit Gerrit Updater added a comment - "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/58693/ Subject: LU-16569 llite: fix file attribute operation Project: fs/lustre-release Branch: master Current Patch Set: Commit: 101b67fcd91617590006c8d16d74401f6489cf8d

          "Yang Sheng <ys@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/58693
          Subject: LU-16569 llite: fix file attribute operation
          Project: fs/lustre-release
          Branch: master
          Current Patch Set: 1
          Commit: 5607a4313d286745aad78cd2bebeb33a28d07ea4

          gerrit Gerrit Updater added a comment - "Yang Sheng <ys@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/58693 Subject: LU-16569 llite: fix file attribute operation Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 5607a4313d286745aad78cd2bebeb33a28d07ea4
          lsattr: Required key not available While reading flags on /mnt/testfs/dir_attr/f-C
          

          I am not even sure why it complains about a 'key' on the file f-C, as it just has a COW-related flag:

          C      A file with the 'C' attribute set will not be subject to
                        copy-on-write updates.  This flag is only supported on
                        file systems which perform copy-on-write.  (Note: For
                        btrfs, the 'C' flag should be set on new or empty files.
                        If it is set on a file which already has data blocks, it
                        is undefined when the blocks assigned to the file will be
                        fully stable.  If the 'C' flag is set on a directory, it
                        will have no effect on the directory, but new files
                        created in that directory will have the No_COW attribute
                        set. If the 'C' flag is set, then the 'c' flag cannot be
                        set.)
          
          sebastien Sebastien Buisson added a comment - lsattr: Required key not available While reading flags on /mnt/testfs/dir_attr/f-C I am not even sure why it complains about a 'key' on the file f-C , as it just has a COW-related flag: C A file with the 'C' attribute set will not be subject to copy-on-write updates. This flag is only supported on file systems which perform copy-on-write. (Note: For btrfs, the 'C' flag should be set on new or empty files. If it is set on a file which already has data blocks, it is undefined when the blocks assigned to the file will be fully stable. If the 'C' flag is set on a directory, it will have no effect on the directory, but new files created in that directory will have the No_COW attribute set. If the 'C' flag is set, then the 'c' flag cannot be set.)

          This definitely looks like it could screw up encrypted files:

          # for F in a A c C d D e F i j m P s S t T u x; do
               touch /mnt/testfs/dir_attr/f-$F
               chattr +$F /mnt/testfs/dir_attr/f-$F
          done
          
          # ls -l /mnt/testfs/dir_attr
          total 0
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-a
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-A
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-c
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-C
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-d
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-D
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-e
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-F
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-i
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-j
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-m
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-P
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-s
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-S
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-t
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-T
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-u
          0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-x
          
          # lsattr /mnt/testfs/dir_attr
          ---------------------- /mnt/testfs/dir_attr/f-F
          ---------------------- /mnt/testfs/dir_attr/f-c
          ---------------------- /mnt/testfs/dir_attr/f-d
          ---------------------- /mnt/testfs/dir_attr/f-D
          ---------------------- /mnt/testfs/dir_attr/f-m
          -------A-------------- /mnt/testfs/dir_attr/f-A
          lsattr: Required key not available While reading flags on /mnt/testfs/dir_attr/f-C
          ---------------------- /mnt/testfs/dir_attr/f-s
          --S------------------- /mnt/testfs/dir_attr/f-S
          ---------------------- /mnt/testfs/dir_attr/f-T
          ---------------------- /mnt/testfs/dir_attr/f-x
          ---------------------- /mnt/testfs/dir_attr/f-u
          -------------------P-- /mnt/testfs/dir_attr/f-P
          -----a---------------- /mnt/testfs/dir_attr/f-a
          ----i----------------- /mnt/testfs/dir_attr/f-i
          ---------------------- /mnt/testfs/dir_attr/f-t
          ---------------------- /mnt/testfs/dir_attr/f-e
          ---------------------- /mnt/testfs/dir_attr/f-j
          

          While I'm not sure the clients should filter the flags (since they may not know which ones the servers support), definitely the MDS should filter the unknown/unsupported flags (or whitelist only known flags). I think there is a flag whitelist in newer ext4 code, not sure what version that appeared in, but we might also bypass those checks in osd-ldiskfs.

          adilger Andreas Dilger added a comment - This definitely looks like it could screw up encrypted files: # for F in a A c C d D e F i j m P s S t T u x; do touch /mnt/testfs/dir_attr/f-$F chattr +$F /mnt/testfs/dir_attr/f-$F done # ls -l /mnt/testfs/dir_attr total 0 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-a 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-A 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-c 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-C 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-d 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-D 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-e 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-F 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-i 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-j 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-m 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-P 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-s 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-S 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-t 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-T 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-u 0 -rw-r--r--. 1 root 0 Feb 17 18:40 f-x # lsattr /mnt/testfs/dir_attr ---------------------- /mnt/testfs/dir_attr/f-F ---------------------- /mnt/testfs/dir_attr/f-c ---------------------- /mnt/testfs/dir_attr/f-d ---------------------- /mnt/testfs/dir_attr/f-D ---------------------- /mnt/testfs/dir_attr/f-m -------A-------------- /mnt/testfs/dir_attr/f-A lsattr: Required key not available While reading flags on /mnt/testfs/dir_attr/f-C ---------------------- /mnt/testfs/dir_attr/f-s --S------------------- /mnt/testfs/dir_attr/f-S ---------------------- /mnt/testfs/dir_attr/f-T ---------------------- /mnt/testfs/dir_attr/f-x ---------------------- /mnt/testfs/dir_attr/f-u -------------------P-- /mnt/testfs/dir_attr/f-P -----a---------------- /mnt/testfs/dir_attr/f-a ----i----------------- /mnt/testfs/dir_attr/f-i ---------------------- /mnt/testfs/dir_attr/f-t ---------------------- /mnt/testfs/dir_attr/f-e ---------------------- /mnt/testfs/dir_attr/f-j While I'm not sure the clients should filter the flags (since they may not know which ones the servers support), definitely the MDS should filter the unknown/unsupported flags (or whitelist only known flags). I think there is a flag whitelist in newer ext4 code, not sure what version that appeared in, but we might also bypass those checks in osd-ldiskfs.

          People

            ys Yang Sheng
            aboyko Alexander Boyko
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: