Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-7094

object UID not being set correctly for non-root user

Details

    • Bug
    • Resolution: Cannot Reproduce
    • Minor
    • None
    • Lustre 2.8.0
    • None
    • Single-node MDS/OSS/client with 2x MDT, 3x OST ldiskfs
      Lustre v2_7_58_0-ga41ac78
    • 3
    • 9223372036854775807

    Description

      Running "rsync -a /etc $MOUNT" to populate a filesystem and then run LFSCK against it, I see that the one file in my /etc not owned by root is not getting the UID set properly, and LFSCK has to fix it:

      # lctl set_param printk=+lfsck
      # lctl lfsck_start -M testfs-MDT0000 -t all -A
      <wait until done>
      # lctl get_param mdd.*testfs-*.lfsck_* | grep "repaired.*: [1-9]"
      repaired_inconsistent_owner: 1
      # dmesg | grep repaired
      Lustre: 19941:0:(lfsck_layout.c:3076:lfsck_layout_repair_owner()) testfs-MDT0001-osd: layout LFSCK assistant repaired inconsistent file owner for: parent [0x240000403:0x257:0x0], child [0x280000400:0x3c:0x0], OST-index 0, stripe-index 0, old owner 0/10000, new owner 10000/10000: rc = 1
      # lfs fid2path /mnt/testfs [0x240000403:0x257:0x0]
      /mnt/testfs//etc3/etc/bash_completion.d/msm
      # ls -ln /etc/bash_completion.d/msm
      8 -rw-rw-r-- 1 10000 10000 7236 Apr 22  2014 /etc/bash_completion.d/msm
      # find /etc ! -uid 0 | less
      /etc/bash_completion.d/msm
      # find /etc ! -gid 0 | less
      /etc/mtab.fuselock
      /etc/pam.d/atd
      /etc/bash_completion.d/msm
      /etc/aliases.db
      /etc/dumpdates
      /etc/ntp/crypto
      

      This is 100% repeatable (i.e. lfsck will find and fix this one file each time it is copied), and not complain about any of the files with GID != 0. I suspect this should be breaking quota for non-root users.

      Attachments

        Issue Links

          Activity

            [LU-7094] object UID not being set correctly for non-root user

            Track patch landing in LU-7301.

            adilger Andreas Dilger added a comment - Track patch landing in LU-7301 .

            Reopen to land testing patch:

            Andreas Dilger (andreas.dilger@intel.com) uploaded a new patch: http://review.whamcloud.com/16237
            Subject: LU-7094 tests: delete old lfsck tests
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: 67ec8ec07788533d2c88492323b0f8819546f530

            adilger Andreas Dilger added a comment - Reopen to land testing patch: Andreas Dilger (andreas.dilger@intel.com) uploaded a new patch: http://review.whamcloud.com/16237 Subject: LU-7094 tests: delete old lfsck tests Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 67ec8ec07788533d2c88492323b0f8819546f530

            Problem appears to have gone away after unloading all modules.

            adilger Andreas Dilger added a comment - Problem appears to have gone away after unloading all modules.

            Seems that some files don't get repaired, even after multiple LFSCK runs:

            Sep  4 01:26:12 lfsck_layout_repair_owner()) testfs-MDT0000-osd: layout LFSCK assistant repaired inconsistent file owner for: parent [0x200000402:0xec1:0x0], child [0x100010000:0x301:0x0], OST-index 1, stripe-index 0, old owner 0/10000, new owner 10000/10000: rc = 1
            Sep  4 01:34:52 lfsck_layout_repair_owner()) testfs-MDT0000-osd: layout LFSCK assistant repaired inconsistent file owner for: parent [0x200000402:0xec1:0x0], child [0x100010000:0x301:0x0], OST-index 1, stripe-index 0, old owner 0/10000, new owner 10000/10000: rc = 1
            Sep  4 01:38:00 lfsck_layout_repair_owner()) testfs-MDT0000-osd: layout LFSCK assistant repaired inconsistent file owner for: parent [0x200000402:0xec1:0x0], child [0x100010000:0x301:0x0], OST-index 1, stripe-index 0, old owner 0/10000, new owner 10000/10000: rc = 1
            Sep  4 01:40:49 lfsck_layout_repair_owner()) testfs-MDT0000-osd: layout LFSCK assistant repaired inconsistent file owner for: parent [0x200000402:0xec1:0x0], child [0x100010000:0x301:0x0], OST-index 1, stripe-index 0, old owner 0/10000, new owner 10000/10000: rc = 1
            

            It makes me wonder if LFSCK isn't getting the UID attribute properly from the inode, or maybe it isn't saving the inode to disk properly? This might relate to LU-6096 since it is possible I haven't reloaded the ldiskfs module since that patch was landed.

            adilger Andreas Dilger added a comment - Seems that some files don't get repaired, even after multiple LFSCK runs: Sep 4 01:26:12 lfsck_layout_repair_owner()) testfs-MDT0000-osd: layout LFSCK assistant repaired inconsistent file owner for: parent [0x200000402:0xec1:0x0], child [0x100010000:0x301:0x0], OST-index 1, stripe-index 0, old owner 0/10000, new owner 10000/10000: rc = 1 Sep 4 01:34:52 lfsck_layout_repair_owner()) testfs-MDT0000-osd: layout LFSCK assistant repaired inconsistent file owner for: parent [0x200000402:0xec1:0x0], child [0x100010000:0x301:0x0], OST-index 1, stripe-index 0, old owner 0/10000, new owner 10000/10000: rc = 1 Sep 4 01:38:00 lfsck_layout_repair_owner()) testfs-MDT0000-osd: layout LFSCK assistant repaired inconsistent file owner for: parent [0x200000402:0xec1:0x0], child [0x100010000:0x301:0x0], OST-index 1, stripe-index 0, old owner 0/10000, new owner 10000/10000: rc = 1 Sep 4 01:40:49 lfsck_layout_repair_owner()) testfs-MDT0000-osd: layout LFSCK assistant repaired inconsistent file owner for: parent [0x200000402:0xec1:0x0], child [0x100010000:0x301:0x0], OST-index 1, stripe-index 0, old owner 0/10000, new owner 10000/10000: rc = 1 It makes me wonder if LFSCK isn't getting the UID attribute properly from the inode, or maybe it isn't saving the inode to disk properly? This might relate to LU-6096 since it is possible I haven't reloaded the ldiskfs module since that patch was landed.
            green Oleg Drokin added a comment -

            I can only replicate this if the source file is empty, so there are no writes to osts and as such the onject ownership does not propagate?

            green Oleg Drokin added a comment - I can only replicate this if the source file is empty, so there are no writes to osts and as such the onject ownership does not propagate?

            People

              adilger Andreas Dilger
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: