[LU-11656] "lfs getstripe" on directory does not show default root layout

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.14.0, Lustre 2.12.4
• Affects Version/s: Lustre 2.12.0, Lustre 2.10.8
• Severity: 3
• Assignee: Jian Yu
• Reporter: Andreas Dilger

Description

Running "lfs getstripe" on a directory only shows the simple filesystem default layout and not the root default layout that will actually be inherited by new files.

# lfs setstripe -p ssd /mnt/testfs
# lfs getstripe -d /mnt/testfs
stripe_count: 1 stripe_size: 1048576 stripe_offset: -1 pool: ssd
# mkdir /mnt/testfs/tmp/should_be_old
# lfs getstripe -d /mnt/testfs/tmp/should_be_old
stripe_count: 1 stripe_size: 1048576 stripe_offset: -1

Issue Links

• is blocking: LU-11918 Allow setting default file layout on root directory at mkfs time
• is related to: LU-12643 PFL layout don't inherit correctly from default layout.
• is related to: LU-13687 interop: "lfs find" prints spurious "No such file or directory" error messages
• is related to: LU-9982 Clients striping from mapped FID in nodemap
• is related to: LU-11739 Don't inherit default layout from root for new subdirectories

Comments

[Jian Yu]

Hi Nathan,
Let me look into this and work on it.

[Nathan Dauchy (Inactive)]

Jian.

I just wanted to make sure you were aware that this is still a problem, even with LU-10629 fixed or deleting the stripe info on a directory so that it should implicitly inherit the filesystem default.  I agree with the statement that Andreas made "We need some way to fetch the actual default layout that will be used when new files will be created in that directory."

Thanks,
Nathan

[Jian Yu]

Thank you, Nathan.

However, "lfs setstripe -d /lfstmp/toplevel" will delete both the striping pattern and OST pool (fixed in LU-10629) on the directory. So, the above test results are correct.

[Nathan Dauchy (Inactive)]

Jian, I wanted to make sure the "explicitly inheriting" issue was clear, as it explains why your test showed different results than the original bug report.  You did everything in the top-level.  So, to reproduce and see that "lfs getstripe" does not actually report the filesystem default, try something like this:

# lfs getstripe -d /lfstmp
stripe_count: 1 stripe_size: 1048576 stripe_offset: -1 pool: OLD
# mkdir /lfstmp/toplevel
# lfs getstripe -d /lfstmp/toplevel
stripe_count: 1 stripe_size: 1048576 stripe_offset: -1 pool: OLD
   (that is the root level Explicit inheritance)

# lfs setstripe -d /lfstmp/toplevel
# lfs getstripe -d /lfstmp/toplevel
stripe_count: 1 stripe_size: 1048576 stripe_offset: -1
# mkdir /lfstmp/toplevel/should_be_old
# lfs getstripe -d /lfstmp/toplevel/should_be_old/
stripe_count: 1 stripe_size: 1048576 stripe_offset: -1
  (neither the top level or new dirs display "OLD", but they should)

Hope this helps!
-Nathan

[Andreas Dilger]

After LU-11739, we shouldn't be explicitly inheriting the layout from the root directory anymore.

However, I think the "lfs getstripe" on directories that do not have an actual LOV EA will only print the stripe_count, stripe_size, and stripe_index that is fetched from the /sys/fs/lustre/lov values.

We need some way to fetch the actual default layout that will be used when new files will be created in that directory. We can't use the layout from the directory of the mountpoint, since that might be a subdirectory mount. One option would be to fetch the layout from the ROOT FID?

[Jian Yu]

Here is the test result on Lustre 2.10.5_ddn6 and master branch:

# lfs getstripe -d /mnt/lustre
stripe_count:  1 stripe_size:   1048576 pattern:       0 stripe_offset: -1

# mkdir /mnt/lustre/olddir
# lfs getstripe -d /mnt/lustre/olddir
stripe_count:  1 stripe_size:   1048576 pattern:       0 stripe_offset: -1

# lfs setstripe -p OLD /mnt/lustre
# lfs getstripe -d /mnt/lustre
stripe_count:  1 stripe_size:   1048576 pattern:       raid0 stripe_offset: -1 pool:          OLD

# lfs getstripe -d /mnt/lustre/olddir
stripe_count:  1 stripe_size:   1048576 pattern:       0 stripe_offset: -1

# mkdir /mnt/lustre/newdir
# lfs getstripe -d /mnt/lustre/newdir
stripe_count:  1 stripe_size:   1048576 pattern:       raid0 stripe_offset: -1 pool:          OLD

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":

lov_dump_plain_user_lmm()

        __u32 magic = *(__u32 *)&param->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 *)&param->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.