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-8820 Lustre <p>Robert has pointed out that there is no need for the copytool to call the LL_IOC_HSM_COPY_START ioctl (which sends a MDS_HSM_PROGRESS) when processing a remove action.</p> LU-8820

skip LL_IOC_HSM_COPY_START for HSM removes

Bug Minor Resolved Fixed John Hammond John Hammond hsm Thu, 10 Nov 2016 16:20:39 +0000 Mon, 24 Apr 2017 15:58:11 +0000 Thu, 16 Mar 2017 22:03:51 +0000 Lustre 2.10.0 0 3 <p>John L. Hammond (john.hammond@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/23700" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/23700</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-8820" title="skip LL_IOC_HSM_COPY_START for HSM removes" class="issue-link" data-issue-key="LU-8820"><del>LU-8820</del></a> hsm: skip LL_IOC_HSM_COPY_START for HSM removes<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: b4f5980394bb77242096b7cc73b606da1b1b773c</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/23700/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/23700/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-8820" title="skip LL_IOC_HSM_COPY_START for HSM removes" class="issue-link" data-issue-key="LU-8820"><del>LU-8820</del></a> hsm: skip LL_IOC_HSM_COPY_START for HSM removes<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 0cc1756e9fb28609705f5f86b8e2197f57b40513</p> <p>Landed for 2.10</p> <p>Since this patch, test_225 does not pass anymore, has this patch altered the behaviour of changelogs?</p> <p>Quentin, test_225() is effectively disabled. The way the CDT is implemented it processes the log sequentially, so it sends the remove, then marks the remove action canceled, then sends the cancel. It's a bit weird, but so is most of the way the CDT code is factored. But I don't see us changing this behavior very soon. Are you running a modified version of test_225()? If this functionality is important to you then could you please explain why?</p> <p>Hi John,</p> <p>I am working on <a href="https://jira.whamcloud.com/browse/LU-8987" title="sanity-hsm: test_225 looks like it was never run" class="issue-link" data-issue-key="LU-8987">LU-8987</a> which aims at enabling test_225 (I merely removed the return statement at the start of the test). The modified test used to pass before this patch. It would seem this patch affected the content of the changelog when a remove request gets canceled. I am just wondering if the new behaviour is the "correct" one or if a regression was masked by test_225 being disabled.</p> <p>test_225 expects a changelog record with the flag 0x27D, from what I gathered in "include/lustre/lustre_user.h" the 0x200 part is related to the HSM_REMOVE operation and the 0x7D means the "HSM return code" is 125.<br/> After this patch the flag is not 0x27D anymore but 0x200.</p> <p>125 is ECANCELED, 0 is success, so this makes sense. I think the new behavior is correct. It's analogous to hitting Ctrl-C just after starting rm vs cp (on a large file). Since rm (unlink()) is atomic, we wouldn't expect the Ctrl-C to prevent the file from being removed. But file copy is not atomic, so we would expect Ctrl-C to do stop the copy.</p> <p>I don't get it, "lfs hsm_remove" is not atomic, so why act as if it were?</p> <p>For tools that rely on parsing the changelogs, this can actually be harmful, a cancelled remove would be interpreted as a successful one, wouldn't it?</p> <p>&gt; I don't get it, "lfs hsm_remove" is not atomic, so why act as if it were?</p> <p>The action performed by the CT for remove is.</p> <p>&gt; For tools that rely on parsing the changelogs, this can actually be harmful, a cancelled remove would be interpreted as a successful one, wouldn't it?</p> <p>I think there's a race that exists with or without this patch. You can cancel a request after the CT has removed the file but before it has reported success. Then how should the request be marked?</p> <p>&gt; The action performed by the CT for remove is.</p> <p>Yes, you are right.</p> <p>&gt;I think there's a race that exists with or without this patch. You can cancel a request after the CT has removed the file but before it has reported success. Then how should the request be marked?</p> <p>I think it is up to the copytool to choose whether and how to act upon receiving a cancel request.</p> <p>So the only "inconsistency" is that the coordinator can report a request as canceled even though it may not be canceled; in which case one can check the changelog records to find out what really happened.</p> Related LU-8987 Development Rank 1|hzyv6n: Rank (Obsolete) 9223372036854775807 Severity