[LU-12481] conf-sanity test_61: setfattr: /mnt/lustre/f61.conf-sanity: Argument list too long

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.13.0
• Severity: 3
• Assignee: Andreas Dilger
• Reporter: Maloo

Description

This issue was created by maloo for Andreas Dilger <[e-mail]>

This issue relates to the following test suite run: https://testing.whamcloud.com/test_sets/80f078fe-6bed-11e9-a6f9-52540065bddc

test_61 failed with the following error in the test logs:

save large xattr trusted.big on /mnt/lustre/f61.conf-sanity
setfattr: /mnt/lustre/f61.conf-sanity: Argument list too long
 conf-sanity test_61: @@@@@@ FAIL: saving trusted.big on /mnt/lustre/f61.conf-sanity failed 
saving trusted.big on /mnt/lustre/f61.conf-sanity failed

The client console log reports -E2BIG = "Argument list too long" as an error:

LustreError: 11-0: lustre-MDT0000-mdc-ffff92be1e196000: operation mds_reint to node 10.9.4.157@tcp failed: rc = -7

and the MDS console log has a matching failure:

LustreError: 17620:0:(mdt_handler.c:2143:mdt_reint_internal()) Can't unpack reint, rc -7

which is failing the check:

int mdt_reint_setxattr()
{
        :
                if (rr->rr_eadatalen > info->mti_mdt->mdt_max_ea_size)
                        RETURN(-E2BIG);

static int mdt_init0(const struct lu_env *env, struct mdt_device *m,
{
        :
        m->mdt_max_ea_size = dt_conf->ddp_max_ea_size;

Where ddp_max_ea_size is fetched from the underlying OSD implementation (ldiskfs only in the case of this test). In this test with ea_inode enabled on the MDT it should be at least 64KB. It looks like the problem is the following code:

static void osd_conf_get(const struct lu_env *env,
{
        :
        if (param->ddp_max_ea_size > OBD_MAX_EA_SIZE - ea_overhead)
                param->ddp_max_ea_size = OBD_MAX_EA_SIZE - ea_overhead;

introduced in patch https://review.whamcloud.com/34058 "LU-11868 osd: Set max ea size to XATTR_SIZE_MAX" landed on 2019-04-30 (which matches the first appearance of the test_61 failures, that limits xattr size, but incorrectly subtracts "ea_overhead" from the maximum xattr size, but this is not needed for xattrs that are stored in an external inode. In that case, the data is aligned to the data blocks in the ea_inode, and the ext4_xattr_entry is stored separately in the parent inode or an external xattr block.

Patch forthcoming.

VVVVVVV DO NOT REMOVE LINES BELOW, Added by Maloo for auto-association VVVVVVV
conf-sanity test_61 - saving trusted.big on /mnt/lustre/f61.conf-sanity failed

Issue Links

• is related to: LU-11868 ZFS ea size limited to 32K

Comments

[Peter Jones]

Landed for 2.13

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/35352/
Subject: LU-12481 osd-ldiskfs: allow full 64KB xattr size
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: da0501850bbe8618b474ca18878b8b260335f6bf

[Gerrit Updater]

Andreas Dilger ([e-mail]) uploaded a new patch: https://review.whamcloud.com/35352
Subject: LU-12481 osd-ldiskfs: allow full 64KB xattr size
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 1ce5b56577f0c7232729a1fbde02ed41ecf25573

[Andreas Dilger]

So there is a separate question of whether the MDS should limit the maximum xattr size to what the client VFS limit is, or if that will be limiting in the future? I've been getting requests to bump the maximum xattr size to 1MB, and to push that to the upstream kernel since 64KB xattrs are becoming limiting for some purposes today. Since the client VFS itself already strongly enforces the 64KB limit, we shouldn't see larger xattrs at the MDS unless the client limit is changed, but if it does change then we will have an artificial limit on the server.