Here is the test result on Lustre 2.10.5_ddn6 and master branch:
The result is different from the description part of this ticket. Actually, running "lfs getstripe" on newly created directory after setting pool name on its parent directory can still show the pool name. Only the directory created before setting pool name on its parent directory has pool name printing issue.
While running "lfs getstripe", the following codes produced the different outputs for "/mnt/lustre" and "/mnt/lustre/olddir":
__u32 magic = *(__u32 *)¶m->fp_lmd->lmd_lmm;
if (magic == LOV_USER_MAGIC_V1) { <------ "/mnt/lustre/olddir" had LOV_USER_MAGIC_V1
lov_dump_user_lmm_v1v3(...);
} else { <------ "/mnt/lustre" had LOV_USER_MAGIC_V3
char pool_name[LOV_MAXPOOLNAME + 1];
struct lov_user_ost_data_v1 *objects;
struct lov_user_md_v3 *lmmv3 = (void *)¶m->fp_lmd->lmd_lmm;
snprintf(pool_name, sizeof(pool_name), "%s",
lmmv3->lmm_pool_name);
objects = lmmv3->lmm_objects;
lov_dump_user_lmm_v1v3(...);
}
After running "lfs setstripe -p OLD" on "/mnt/lustre", its magic was changed from LOV_USER_MAGIC_V1 to LOV_USER_MAGIC_V3 in lod_xattr_set(). However, the previously created "/mnt/lustre/olddir" still had magic of LOV_USER_MAGIC_V1 and was not changed.
Jian, is the default layout for the directory going to be fetched from the ROOT FID inside the kernel or from the "lfs getstripe" command? Fetching it from the kernel simplifies some issues for userspace applications, but has the drawback that tools like "tar" will make a copy of the default trusted.lov xattr for every directory in the filesystem which doesn't have its own xattr.
Doing it in "lfs getstripe" avoids this issue, but may have other issues (e.g. opening $MOUNT/.lustre/fid is only accessible to root, and is not available in subdirectory mounts.