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-3616 Lustre <p>Using the Jul 22, 2013 HSM stack, executing a released file (and thereby triggering a restore) leaves the file writable while it's being executed.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># cd /mnt/lustre # cp /bin/sleep SLEEP # lfs hsm_archive SLEEP # sleep 1 # lfs hsm_release SLEEP # ./SLEEP 10 &amp;&amp; echo DONE &amp; [1] 4243 # sleep 1 # pgrep -l SLEEP 4244 SLEEP # cd /mnt/lustre2 # echo 'Hi!' &gt; SLEEP # cat SLEEP Hi! # -bash: line 238: 4244 Bus error (core dumped) ./SLEEP 10 [1]+ Exit 135 ./SLEEP 10 &amp;&amp; echo DONE (wd: /mnt/lustre) (wd now: /mnt/lustre2) </pre> </div></div> LU-3616

HSM restore for execute allows writes to file

Technical task LU-3647 Major Resolved Fixed Bruno Faccini John Hammond HSM Mon, 22 Jul 2013 18:45:25 +0000 Tue, 31 Dec 2013 15:51:33 +0000 Fri, 25 Oct 2013 13:24:51 +0000 Lustre 2.5.0 Lustre 2.6.0 Lustre 2.5.1 0 8 <p>Normal (without HSM actions/cmds) behavior would be to have "echo 'Hi!' &gt; SLEEP" fail with "Text file busy"/ETXTBSY.</p> <p>And dual/lustre2 mount access is the key ...</p> <p>I am walking thru the code to see where we missed something during hsm_release.</p> <p>This behavior has been introduced in both mdt_mfd_open()/mdt_object_open_lock() routine (in lustre/mdt/mdt_open.c) by commit c42b426c87c3d3b1dc9eda612cc831293dc80d68 from Gerrit patch/Change-Id Ic8f82ddc9a56206307c2e5be2523fb7ce42b8638 (at <a href="http://review.whamcloud.com/3035" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/3035</a>) for LU-1338 (now HSM-5) ticket.</p> <p>And Oleg already warned about this in its Change comment !</p> <p>I wonder if I can simply revert these changes to get the correct behavior, and I would like to get Aurelien (since he is the original change author) feed-back on this.</p> <p>I did not write this part of the patch, but it seems it could be change. I'm trusting Oleg regarding this.<br/> If this fix the code snippet you've posted, I'm fine. Just ensure restore at exec it is still working.</p> <p>1st patch attempt is at <a href="http://review.whamcloud.com/7636" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7636</a>. Build is ok but auto-tests never started ...<br/> So, I just re-triggered auto-tests.</p> <p>1st patch-set of <a href="http://review.whamcloud.com/7636" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7636</a> successfully passed auto-tests and also did not trigger the original problem when running John's reproducer.</p> <p>I will submit a new version/patch-set #2 with the same code but adding a specific+new sub-test in sanity-hsm, based on John's reproducer.</p> <p>Patch-set #2 of Change #7636 successfully passed auto-tests including its own+new sanity-hsm/test_30c sub-test.</p> <p>This allows restore on exec() to continue to work but now prevents any write to be allowed during exec() and make it fail.</p> <p>BTW, reading code of sub-tests test_30<span class="error">&#91;a,b&#93;</span>, against same exec() on released files area, I have been surprised by the following comment :</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># restore at exec cannot work on agent node (because of Linux kernel # protection of executables) needclients 2 || return 0 ... </pre> </div></div> <p>at their beginning. <br/> Is it (comment and "needclients 2") still of actuality, because as per my latest tests, restore at exec() also works on Agent-Node (I mean I tested on a single+full node ...) ?</p> <p>Landed for 2.6</p> <p>This should also be considered for 2.5.1</p> <p>Yes it is being tracked for 2.5.1.</p> Development Rank 1|hzvvu7: Rank (Obsolete) 9297