[LU-7268] lfsck touch an EA inode

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.5.0, Lustre 2.8.0
• Fix Version/s: Lustre 2.8.0
• Type: Bug
• Priority: Major
• Reporter: Alexey Lyashkov
• Assignee: nasf (Inactive)
• Resolution: Fixed
• Severity: 3

Description

While looking to images addressed by LU-7267 and LU-7261 i found someone touch an EA inode and assing an LMA xattr while it should be don't assigned.
Primary candidate is lfsck & oi scrub function.
simple example of debugfs output about such problem.

debugfs:  stat <755994480>
Inode: 755994480   Type: regular    Mode:  0644   Flags: 0x0
Generation: 1724366779    Version: 0x0000004c:072b442f
User: 129712   Group:  2029   Size: 0
File ACL: 0    Directory ACL: 0
Links: 226   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x55ded69a:00000000 -- Thu Aug 27 02:21:30 2015
 atime: 0x55dabf13:00000000 -- Sun Aug 23 23:52:03 2015
 mtime: 0x555d9304:00000000 -- Thu May 21 01:10:44 2015
crtime: 0x55dabf13:0478673c -- Sun Aug 23 23:52:03 2015
Size of extra inode fields: 28
Extended attributes stored in inode body: 
  lma = "00 00 00 00 00 00 00 00 3c 97 0a 00 02 00 00 00 90 52 01 00 00 00 00 00 " (24)
  lma: fid=[0x2000a973c:0x15290:0x0] compat=0 incompat=0
  lov = "d0 0b d1 0b 01 00 00 00 90 52 01 00 00 00 00 00 3c 97 0a 00 02 00 00 00 00 00 10 00 01 00 00 00 0d 54 cd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4c 00 00 00 " (56)
  link = "inode <756015528>" (5674)
BLOCKS:

debugfs:  stat <756015528>
Inode: 756015528   Type: regular    Mode:  0600   Flags: 0x200000
Generation: 1724366779    Version: 0x00000000:00000000
User:     0   Group:     0   Size: 5674
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 16
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x55ded69a:85bc9fe4 -- Thu Aug 27 02:21:30 2015
 atime: 0x55ded69a:85bc9fe4 -- Thu Aug 27 02:21:30 2015
 mtime: 0x2d0f8f70:85bc9fe4 -- Wed Dec 15 14:28:00 1993
crtime: 0x55ded69a:85bc9fe4 -- Thu Aug 27 02:21:30 2015
Size of extra inode fields: 28
Extended attributes stored in inode body: 
  lma = "00 00 00 00 00 00 00 00 a8 e1 0f 2d 00 00 00 00 bb bf c7 66 00 00 00 00 " (24)
  lma: fid=[0x2d0fe1a8:0x66c7bfbb:0x0] compat=0 incompat=0
BLOCKS:
(0-1):755923858-755923859
TOTAL: 2

Comments

[Joseph Gmitter (Inactive)]

Hi Fan Yong,
Can you have a look at this one?
Thanks.
Joe

[Andreas Dilger]

This isn't in itself harmful, because the LMA xattr on the xattr inode is not visible or accessible by anything, only the data blocks are used by ldiskfs.

That said, it is confusing that OI Scrub is adding the LMA to this inode. It should skip inodes with the EXT4_EA_INODE_FL flag set.

[Alexey Lyashkov]

It may produce a problems with OI. Like unreclaimable entries. simple example
OI Scrub fill LMA and put record to OI, but none operations will remove it record from OI table.
May be other problems when two keys point to same inode number.

[Gerrit Updater]

Fan Yong ([e-mail]) uploaded a new patch: http://review.whamcloud.com/17043
Subject: LU-7268 scrub: NOT assign LMA for EA inode
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 189878cabee229c08a0c1e0caa0860780bafbc98

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/17043/
Subject: LU-7268 scrub: NOT assign LMA for EA inode
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: af46e574eeebe23c5a6146a134fa00ee91931de3

[nasf (Inactive)]

The patch has been landed to master.