[LU-16835] lustre-initialization: Operation not supported while trying to set fs label, tune2fs 1.47.0-wc1 Created: 17/May/23 Updated: 04/Jul/23 |
|
| Status: | Open |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.16.0 |
| Fix Version/s: | Lustre 2.16.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Maloo | Assignee: | Dongyang Li |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||
| Severity: | 3 | ||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||
| Description |
|
This issue was created by maloo for Andreas Dilger <adilger@whamcloud.com> This issue relates to the following test suite runs: lustre-initialization failed with the following error: 2023-05-12T14:31:49 CMD: onyx-113vm10 mkdir -p /mnt/lustre-mds1; mount -t lustre -o localrecov /dev/mapper/mds1_flakey /mnt/lustre-mds1
2023-05-12T14:31:49 /mnt/lustre-mds1: Operation not supported while trying to set fs label
2023-05-12T14:31:49 tune2fs 1.47.0-wc1 (28-Apr-2023)
2023-05-12T14:31:54 CMD: onyx-113vm10 e2label /dev/mapper/mds1_flakey 2>/dev/null | grep -E ':[a-zA-Z]{3}[0-9]{4}'
2023-05-12T14:31:54 pdsh@onyx-91vm5: onyx-113vm10: ssh exited with exit code 1
2023-05-12T14:31:54 Commit the device label on /dev/lvm-Role_MDS/P1
2023-05-12T14:31:54 CMD: onyx-113vm10 sync; sleep 1; sync
2023-05-12T14:31:59 CMD: onyx-113vm10 e2label /dev/mapper/mds1_flakey 2>/dev/null
2023-05-12T14:31:59 pdsh@onyx-91vm5: onyx-113vm10: ssh exited with exit code 1
2023-05-12T14:31:59 no label for /dev/mapper/mds1_flakey
Test session details: This may be related to the update to use e2fsprogs-1.47.0-wc1, which may have added support for new ioctl() to get/set the filesystem label (FS_IOC_GETFSLABEL and FS_IOC_SETFSLABEL) but this was added only in kernel v5.16-rc4-36-gbbc605cdb1e1. It may be that the fallback for older kernels is not working? VVVVVVV DO NOT REMOVE LINES BELOW, Added by Maloo for auto-association VVVVVVV |
| Comments |
| Comment by Andreas Dilger [ 19/May/23 ] |
|
It looks like e2fsprogs upstream commit v1.46.5-78-ga83e199da "tune2fs: Add support for get/set UUID ioctls" is at least partly responsible for this issue. It may also relate to an update to the kernel that backported these ioctls to an older kernel that is triggering the error, or possibly it was never tested on an older kernel without this functionality? |
| Comment by Andreas Dilger [ 19/May/23 ] |
|
It looks like this error might be coming from the following code in ext4_ioctl():
/*
* If any checksums (group descriptors or metadata) are being used
* then the checksum seed feature is required to change the UUID.
*/
if (((ext4_has_feature_gdt_csum(sb) || ext4_has_metadata_csum(sb))
&& !ext4_has_feature_csum_seed(sb))
|| ext4_has_feature_stable_inodes(sb))
return -EOPNOTSUPP;
since we do not enable the EXT4_FEATURE_INCOMPAT_CSUM_SEED on any Lustre filesystems, since we also do not handle the METADATA_CSUM feature. However, we do enable GDT_CSUM, which seems to be tripping this check up. However, tune2fs should just ignore any such error and fall back to modify the superblock directly in that case. It looks like the bug is at: + + ret = -1; +#ifdef __linux__ + if (fsuuid) { + fsuuid->fsu_len - UUID_SIZE; + fsuuid->fsu_flags = 0; + memcpy(&fsuuid->fsu_uuid, new_uuid, UUID_SIZE); + ret = ioctl(fd, EXT4_IOC_SETFSUUID, fsuuid); + } +#endif + ret = -1; + /* + * If we can't set the UUID via the ioctl, fall + * back to directly modifying the superblock + .*/ + if (ret) { + memcpy(sb->s_uuid, new_uuid, UUID_SIZE); + ext2fs_init_csum_seed(fs); + if (set_csum) { + for (i = 0; i < fs->group_desc_count; i++) + ext2fs_group_desc_csum_set(fs, i); + fs->flags &= ~EXT2_FLAG_SUPER_ONLY; + } + ext2fs_mark_super_dirty(fs); } In the fallback case (with Linux, and newer kernel that has EXT4_IOC_SETFSUUID but filesystem with no CSUM_SEED feature), it does not clear "ret" so "errno = EOPNOTSUPP" returned from the kernel is still hit. |
| Comment by Gerrit Updater [ 19/May/23 ] |
|
|
| Comment by Dongyang Li [ 20/May/23 ] |
|
I used bpftrace and it confirms ioctl((FS_IOC_GETFSLABEL) does return EOPNOTSUPP as the error message suggested. Adding EOPNOTSUPP check in tune2fs will work, but I doubt upstream will like it, server_ioctl() should really just return ENOTTY and e2label will fallback to old ways to set/get label. Now, ATM-2790 actually shows a different issue, the handle_fslable() from tune2fs just quits if it fails to open the mount point. I think in this case we should just fallback to old method as well and no com_err is needed. |
| Comment by Gerrit Updater [ 20/May/23 ] |
|
"Li Dongyang <dongyangli@ddn.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/51072 |
| Comment by Gerrit Updater [ 20/May/23 ] |
|
"Li Dongyang <dongyangli@ddn.com>" uploaded a new patch: https://review.whamcloud.com/c/tools/e2fsprogs/+/51073 |
| Comment by Gerrit Updater [ 22/May/23 ] |
|
|
| Comment by Gerrit Updater [ 22/May/23 ] |
|
"Andreas Dilger <adilger@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/51072/ |
| Comment by Gerrit Updater [ 25/May/23 ] |
|
"Li Dongyang <dongyangli@ddn.com>" merged in patch https://review.whamcloud.com/c/tools/e2fsprogs/+/51073/ |