Details
-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
None
-
VMs on Lustre master (2.14.54_98_g3db8e31)
-
3
-
9223372036854775807
Description
Here are the changelogs that we can see while restoring a hsm file:
30 10OPEN 10:43:26.912661570 2021.10.15 0xcb t=[0x200000402:0xa:0x0] j=lhsmtool_posix.0 ef=0xf u=0:0 nid=10.0.2.6@tcp m=rw- 31 10OPEN 10:43:26.920553291 2021.10.15 0x2 t=[0x200000402:0xa:0x0] j=lhsmtool_posix.0 ef=0xf u=0:0 nid=10.0.2.6@tcp m=-w- 32 16HSM 10:43:26.966607124 2021.10.15 0x0 t=[0x200000402:0x1:0x0] j=lhsmtool_posix.0 ef=0xf u=0:0 nid=10.0.2.6@tcp 33 12LYOUT 10:43:26.967682430 2021.10.15 0x0 t=[0x200000402:0x1:0x0] j=lhsmtool_posix.0 ef=0xf u=0:0 nid=10.0.2.6@tcp 34 16HSM 10:43:26.969154222 2021.10.15 0x80 t=[0x200000402:0x1:0x0] j=lhsmtool_posix.0 ef=0xf u=0:0 nid=10.0.2.6@tcp
The changelog 32 is wrong: flag: 0x0 -> err=0 hsm_event: HE_ARCHIVE hsm_flag=0
The changelog 34 is the right one: 0x80 -> err=0 hsm_event: HE_RESTORE hsm_flag=0
I think changelog 32 should be set flag to 0x280: err=0 hsm_event: HE_STATE hsm_flag=0
The wrong flag is positioned because of the following code (when updating hsm state attr):
static int mdd_hsm_update_locked(const struct lu_env *env, struct md_object *obj, const struct lu_buf *buf, struct thandle *handle, enum changelog_rec_flags *clf_flags) { ..... /* Flags differ, set flags for the changelog that will be added */ if (current_mh->mh_flags != new_mh->mh_flags) { <---------- hsm_set_cl_event(clf_flags, HE_STATE); if (new_mh->mh_flags & HS_DIRTY) hsm_set_cl_flags(clf_flags, CLF_HSM_DIRTY); }
When restoring a file, hsm xattr is updated by hsm_swap_layouts on the volatile (so no changelog are emitted there):
static int hsm_swap_layouts(struct mdt_thread_info *mti, struct mdt_object *obj, const struct lu_fid *dfid, struct md_hsm *mh_common) { ..... mh_common->mh_flags &= ~(HS_RELEASED | HS_DIRTY); rc = mdt_hsm_attr_set(mti, dobj, mh_common);
So empty HSM changelog is issued by hsm_cdt_request_completed() -> mdt_hsm_attr_set() because hsm state is not modified by this function.
I have updated the patch above to take into account Thomas's remark.