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

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.8.0
• Type: Bug
• Priority: Minor
• Reporter: Andreas Dilger
• Assignee: Andreas Dilger
• Resolution: Cannot Reproduce

Environment

Single-node MDS/OSS/client with 2x MDT, 3x OST ldiskfs
Lustre v2_7_58_0-ga41ac78

• Severity: 3

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.

Issue Links

• duplicates: LU-6096 sanity test_17m: e2fsck Inode 32775, ...
• is related to: LU-7301 change test-framework to exclude the ...

Comments

[Oleg Drokin]

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?

[Andreas Dilger]

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.

[Andreas Dilger]

Problem appears to have gone away after unloading all modules.

[Andreas Dilger]

Reopen to land testing patch:

Andreas Dilger ([e-mail]) 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

[Andreas Dilger]

Track patch landing in LU-7301.