[LU-12784] interop: sanity test 102ha fails with “saving trusted.big on /mnt/lustre/f102ha.sanity failed” Created: 18/Sep/19 Updated: 13/Dec/21 Resolved: 23/Oct/19 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.13.0 |
| Fix Version/s: | Lustre 2.13.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | James Nunez (Inactive) | Assignee: | Patrick Farrell |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | interop | ||
| Environment: |
Clients with Lustre version 2.12.53 or later and any server with version < 2.12.53 |
||
| Severity: | 3 |
| Rank (Obsolete): | 9223372036854775807 |
| Description |
|
sanity test_102ha fails with “saving trusted.big on /mnt/lustre/f102ha.sanity failed” for master (2.13.0) client and 2.12.2 servers. This test started to fail in interop testing on 03-JUNE-2019. Looking at the client test_log, we see == sanity test 102ha: grow xattr from inside inode to external inode ================================= 03:09:44 (1568344184) CMD: trevis-5vm8 dumpe2fs -h /dev/mapper/mds1_flakey 2>&1 | grep -E -q '(ea_inode|large_xattr)' CMD: trevis-5vm8 dumpe2fs -h /dev/mapper/mds1_flakey 2>&1 | grep -E -q '(ea_inode|large_xattr)' setting xattr of max xattr size: 1048364 CMD: trevis-5vm8 dumpe2fs -h /dev/mapper/mds1_flakey 2>&1 | grep -E -q '(ea_inode|large_xattr)' save trusted.big on /mnt/lustre/f102ha.sanity /usr/lib64/lustre/tests/sanity.sh: line 8946: /usr/bin/setfattr: Argument list too long sanity test_102ha: @@@@@@ FAIL: saving trusted.big on /mnt/lustre/f102ha.sanity failed Trace dump: = /usr/lib64/lustre/tests/test-framework.sh:6115:error() = /usr/lib64/lustre/tests/sanity.sh:8947:grow_xattr() = /usr/lib64/lustre/tests/sanity.sh:8984:test_102ha() The patch https://review.whamcloud.com/34058 modified sanity test 102hs and the function grow_xattr() to take a “toobig” parameter. |
| Comments |
| Comment by Patrick Farrell (Inactive) [ 18/Sep/19 ] |
|
Hmm. This appears to come down to the older server advertising the max xattr size differently in a way that means for large xattrs, it's advertising a slightly larger size than it can actually support. This is for ldiskfs, with our old ~1 MiB xattr limit. It's not an issue for smaller sizes, or so it seems. As discussed with Andreas, I think the proper thing to do is limit max attr size (in the test scripts) used with older servers to the current XATTR_SIZE_MAX (the kernel constant), 64 KiB. This should avoid the problem where the older server doesn't properly advertise its xattr size limit, but still let us use the maximum xattr size with newer servers. I'll push a patch in a bit. |
| Comment by Gerrit Updater [ 19/Sep/19 ] |
|
Patrick Farrell (pfarrell@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36240 |
| Comment by Gerrit Updater [ 22/Oct/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36240/ |
| Comment by Peter Jones [ 23/Oct/19 ] |
|
Landed for 2.13 |
| Comment by Gerrit Updater [ 15/Oct/21 ] |
|
"Andreas Dilger <adilger@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/45264 |
| Comment by Gerrit Updater [ 13/Dec/21 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/45264/ |