https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-3882 Lustre <p>Due to the global KUC lists, seeing IMP_EVENT_ACTIVE on any MDC import will cause any already registered CT archive masks to be registered with the MDT behind that import.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>mdc_import_event(..., ..., imp, IMP_EVENT_ACTIVE) mdc_kuc_reregister(imp) libcfs_kkuc_group_foreach(KUC_GRP_HSM, mdc_hsm_ct_reregister, imp) (void *)imp) cfs_list_for_each_entry(reg, ... KUC_GRP_HSM, ...) mdc_hsm_ct_reregister(reg-&gt;kr_reg = archives, imp) mdc_ioc_hsm_ct_register(imp, archives) /* Send MDS_HSM_CT_REGISTER. */ </pre> </div></div> LU-3882

mounting a Lustre FS when already running an HSM CT causes the new mount to register as a CT

Technical task LU-3647 Major Resolved Fixed John Hammond John Hammond HSM Wed, 4 Sep 2013 22:28:47 +0000 Wed, 2 Oct 2013 20:16:26 +0000 Wed, 2 Oct 2013 20:16:26 +0000 Lustre 2.5.0 Lustre 2.5.0 0 8 <p>It could be fixed like this:</p> <ul> <li>add mount point identifier as new argument of libcfs_ukuc_start() to put it into kkuc_reg structure.</li> <li>add mount point identifier as new argument of libcfs_kkuc_group_foreach() so it only runs the re-registration for copytools who registered on this mount point.</li> </ul> <p>I see this comment in kuc:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>/* Broadcast groups are global across all mounted filesystems; * i.e. registering for a group on 1 fs will get messages for that * group from any fs */ </pre> </div></div> <p>And indeed it appears that a copytool registered for 1 filesystem will get requests for other filesystems.<br/> in mdc:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> /* Broadcast to HSM listeners */ rc = libcfs_kkuc_group_put(KUC_GRP_HSM, lh); </pre> </div></div> <p>The only check is done in the copytool code itself, based on hsm action list contents:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> if (strcmp(hal-&gt;hal_fsname, fs_name) != 0) { CT_ERROR("'%s' invalid fs name, expecting: %s\n", hal-&gt;hal_fsname, fs_name); </pre> </div></div> <p>It would be better to filter it before, in the kuc layer, by adding the mnt point parameter to libcfs_kkuc_group_put() too.</p> <p>Thomas,<br/> Are you planning to submit a patch for this?</p> <p>Thomas is off for the next days. I can work on a patch if needed.<br/> We would appreciate comments/suggestions from Intel on the proposed approach though.</p> <p>I agree with Thomas' approach but think it can be refined somewhat. Here is what I suggest:</p> <ol> <li>In struct struct kkuc_reg change kr_data from __u32 to void *.</li> <li>Define struct kkuc_ct_data as follows to hold some magic, an obd_uuid, and the __u32 archive formerly placed in kr_data.</li> <li>In lmv_hsm_ct_register() allocate a kkuc_ct_data and initialize it with the UUID of the LMV obd and with the passed in archives.</li> <li>In libcfs_kkuc_group_rem() add a void **data parameter to receive the data on removal.</li> <li>In lmv_hsm_ct_unregister() recover the kkuc_ct_data and free it.</li> <li>Adjust mdc_hsm_ct_reregister() to use kkuc_ct_data and check its UUID against that of the MDC import.</li> </ol> <p>Thanks a lot John.</p> <p>Patch is at <a href="http://review.whamcloud.com/7612" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7612</a></p> <p>Landed for 2.5.0</p> Development Rank 1|hzw007: Rank (Obsolete) 10080