[LU-16085] Ubuntu 22.04 sanityn test_106c: supported stx_attributes: got '2030', expected '30'

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.15.1
• Fix Version/s: Lustre 2.16.0, Lustre 2.15.2
• Type: Bug
• Priority: Minor
• Reporter: Maloo
• Assignee: Sebastien Buisson
• Resolution: Fixed
• Severity: 3

Description

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

This issue relates to the following test suite run: https://testing.whamcloud.com/test_sets/d93ea6cd-9f2e-4488-84c9-da7169aaac3c

test_106c failed with the following error:

supported stx_attributes: got '2030', expected '30'

It is similar as LU-13628 but this is with Ubuntu2204 client

== sanityn test 106c: Verify statx attributes mask ======= 11:30:40 (1660044640)
 sanityn test_106c: @@@@@@ FAIL: supported stx_attributes: got '2030', expected '30' 

VVVVVVV DO NOT REMOVE LINES BELOW, Added by Maloo for auto-association VVVVVVV
sanityn test_106c - supported stx_attributes: got '2030', expected '30'

Issue Links

• is related to: LU-10026 Client-side data compression
• is related to: LU-12275 Client-side file data encryption
• is related to: LU-13717 Client-side encryption - support file...
• is related to: LU-12480 add STATX_PROJID to upstream kernel

Comments

[Andreas Dilger]

It looks like this is a new addition to the statx() call since commit v5.7-rc4-9-g80340fe3605c (Ubuntu 22.04 using 5.15.0-39) that adds:

#define STATX_ATTR_MOUNT_ROOT           0x00002000 /* Root of a mount */

That said, I'm not sure why STATX_ATTR_MOUNT_ROOT would be set on a file?

so the test should be changed to expect at least the 0x30 flag:

        # Mask supported in stx_attributes by Lustre is
        # STATX_ATTR_IMMUTABLE(0x10) | STATX_ATTR_APPEND(0x20) : (0x30).
        (( 0x$mask & 0x30 == 0x30 )) ||
                error "supported stx_attributes: got '0x$mask', expected '0x30' at least"

It looks like we should add STATX_ATTR_ENCRYPTED to the list also. This should be set in the stat->attributes_mask in ll_getattr() if those flags are even possible for the filesystem, and then in the returned stat->attributes if the flags are actually set on the inode. It isn't totally clear what to do on a client where the server does not support fscrypt, but I'd guess we leave out the STATX_ATTR_ENCRYPTED flag in that case? The same will need to be done for STATX_ATTR_COMPRESSED in the future.

The ll_getattr() code also can return (via ll_inode_to_ext_flags()) the LUSTRE_SYNC_FL and LUSTRE_DIRSYNC_FL, so I'm wondering if those should also be returned in stat->attributes_mask, even though they are not defined for statx, or if stat->attributes should be masked out by the defined STATX_ATTR_* values in attributes_mask to avoid future conflicts?

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/48208
Subject: LU-16085 llite: fix stat attributes_mask
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 5369d4ecd1e081f48098d153a70b58da807d192a

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/48208/
Subject: LU-16085 llite: fix stat attributes_mask
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 0e48653c27eacad29dbff1589da771ad4f5d1014

[Gerrit Updater]

"Sebastien Buisson <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/48404
Subject: LU-16085 llite: fix stat attributes_mask
Project: fs/lustre-release
Branch: b2_15
Current Patch Set: 1
Commit: 85ad0d58b0a0e101e89ab36344267e0392f74e23

[Peter Jones]

Landed for 2.16