<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:54:57 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Whamcloud Community JIRA</title>
    <link>https://jira.whamcloud.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.4.14</version>
        <build-number>940014</build-number>
        <build-date>05-12-2023</build-date>
    </build-info>


<item>
            <title>[LU-5836]  Error &quot;Device or resource busy&quot; after attempting release of file cleared from &apos;dirty&apos;</title>
                <link>https://jira.whamcloud.com/browse/LU-5836</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;I can consistently replicate this error message.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;# Write a file
$ dd &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;=/dev/zero of=file01 bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00335841 s, 312 MB/s

# Archive the file
$ sudo lfs hsm_archive file01

# Wait &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; file to archive 

# Write to file to make it &lt;span class=&quot;code-quote&quot;&gt;&apos;dirty&apos;&lt;/span&gt;
$ echo &lt;span class=&quot;code-quote&quot;&gt;&quot;0&quot;&lt;/span&gt; &amp;gt;&amp;gt; file01

# Clear the dirty state
$ lfs hsm_clear --dirty file01

# Attempt to release the file
$ sudo lfs hsm_release file02
Cannot send HSM request (use of file02): Device or resource busy
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I suppose it might make sense that a file should not be released if it is truly dirty.  But the error message does not seem to be appropriate.  Perhaps it should not even be possible to clear a &apos;dirty&apos; state&lt;/p&gt;

&lt;p&gt;This is a comment from another person I&apos;ve consulted on this:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;The error comes from  the MDT:&lt;/p&gt;

&lt;p&gt;00000004:20000000:0.0:1414607590.182318:0:1585:0:(mdt_open.c:2042:mdt_hsm_release()) [0x2000013c2:0x116c3:0x0] data_version mismatches: packed=4313503196 and on-disk=4313503194&lt;/p&gt;

&lt;p&gt;so it doesn&apos;t set the OBD_MD_FLRELEASED bit, and the client in turn returns EBUSY.&lt;/p&gt;

&lt;p&gt;No idea what that means though.&lt;/p&gt;&lt;/blockquote&gt;</description>
                <environment>CentOS 6</environment>
        <key id="27400">LU-5836</key>
            <summary> Error &quot;Device or resource busy&quot; after attempting release of file cleared from &apos;dirty&apos;</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="4" iconUrl="https://jira.whamcloud.com/images/icons/priorities/minor.svg">Minor</priority>
                        <status id="1" iconUrl="https://jira.whamcloud.com/images/icons/statuses/open.png" description="The issue is open and ready for the assignee to start work on it.">Open</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="wc-triage">WC Triage</assignee>
                                    <reporter username="moea">Andrew Moe</reporter>
                        <labels>
                            <label>HSM</label>
                            <label>patch</label>
                    </labels>
                <created>Fri, 31 Oct 2014 18:57:18 +0000</created>
                <updated>Mon, 14 Sep 2015 16:36:25 +0000</updated>
                                            <version>Lustre 2.5.2</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>11</watches>
                                                                            <comments>
                            <comment id="115985" author="gerrit" created="Wed, 20 May 2015 09:07:58 +0000"  >&lt;p&gt;Ulka Vaze (ulka.vaze@yahoo.in) uploaded a new patch: &lt;a href=&quot;http://review.whamcloud.com/14874&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/14874&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-5836&quot; title=&quot; Error &amp;quot;Device or resource busy&amp;quot; after attempting release of file cleared from &amp;#39;dirty&amp;#39;&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-5836&quot;&gt;LU-5836&lt;/a&gt; hsm: Error &quot;Device or resource busy&quot;&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: e5add76876f45e3a64c0af0af1ecd288ca2cffc3&lt;/p&gt;</comment>
                            <comment id="115989" author="uvaze" created="Wed, 20 May 2015 09:33:50 +0000"  >&lt;p&gt;Here is Analysis of this issue-&lt;/p&gt;

&lt;p&gt;1. Since dirty flag is cleared request goes to coordinator.&lt;br/&gt;
2. However coordinator check the version of requested file  and version of archived copy. and throws following error &lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;00000004:20000000:0.0:1432012500.276456:0:14313:0:(mdt_open.c:1638:mdt_hsm_release()) [0x200000400:0x1:0x0] data_version mismatches: packed=120259085297 and on-disk=68719476768
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Here it finds version is mismatched so returns request with error  EPERM&lt;br/&gt;
3. However for any error we do not set OBD_MD_FLRELEASED &lt;br/&gt;
4. So when we return call to agent it throws error EBUSY&lt;br/&gt;
Following  is code snippet from ll_close_inode_openhandle (llite/file.c)&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;if (rc == 0 &amp;amp;&amp;amp; op_data-&amp;gt;op_bias &amp;amp; MDS_HSM_RELEASE) {
        struct mdt_body *body;
        body = req_capsule_server_get(&amp;amp;req-&amp;gt;rq_pill, &amp;amp;RMF_MDT_BODY);
       
        if (!(body-&amp;gt;mbo_valid &amp;amp; OBD_MD_FLRELEASED)) {
                            rc = -EBUSY;
           
        }

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;4. EBUSY is misleading message and we  should propagate EPERM message coming from coordinator&lt;/p&gt;

&lt;p&gt;So proposed solution is -&lt;br/&gt;
1.Added one more flag OBD_MD_FLDIRTY which will be set on EPERM.&lt;br/&gt;
This is because there might be cases when we need to return EBUSY. So this will distinguish the case&lt;br/&gt;
2.in llite above function check for this flag is added and return EPERM&lt;/p&gt;

&lt;p&gt;Code is pushed for review.&lt;/p&gt;

&lt;p&gt;Test logs -&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;[root@cli-3 ~]# echo &quot;test&quot; &amp;gt;&amp;gt; /mnt/lustre2/testfile2
[root@cli-3 ~]# lfs hsm_state /mnt/lustre2/testfile2
/mnt/lustre2/testfile2: (0x00000000)
[root@cli-3 ~]# lfs hsm_archive /mnt/lustre2/testfile2
***** FD =  3 PATH = /mnt/lustre2/testfile2 *****
[root@cli-3 ~]# lfs hsm_state   /mnt/lustre2/testfile2
/mnt/lustre2/testfile2: (0x00000009) exists archived, archive_id:1
[root@cli-3 ~]# echo xxx &amp;gt;&amp;gt; /mnt/lustre2/testfile2
[root@cli-3 ~]# lfs hsm_state   /mnt/lustre2/testfile2
/mnt/lustre2/testfile2: (0x0000000b) exists dirty archived, archive_id:1
[root@cli-3 ~]# lfs hsm_clear --dirty /mnt/lustre2/testfile2
[root@cli-3 ~]# lfs hsm_state   /mnt/lustre2/testfile2
/mnt/lustre2/testfile2: (0x00000009) exists archived, archive_id:1
[root@cli-3 ~]# lfs hsm_release /mnt/lustre2/testfile2
***** FD =  3 PATH = /mnt/lustre2/testfile2 *****
Cannot send HSM request (use of /mnt/lustre2/testfile2): Operation not permitted

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

</comment>
                            <comment id="126897" author="panditadityashreesh" created="Thu, 10 Sep 2015 12:43:34 +0000"  >&lt;p&gt;Can you please review it?&lt;/p&gt;</comment>
                            <comment id="126912" author="paf" created="Thu, 10 Sep 2015 15:09:39 +0000"  >&lt;p&gt;This looks like an OK way to get the result Ulka explains in the comment above, but I&apos;m not sure it&apos;s the correct result.  -EPERM is also not a correct error here, is it?&lt;/p&gt;

&lt;p&gt;This is a design level question I don&apos;t have an answer for:&lt;br/&gt;
Shouldn&apos;t clearing the dirty flag, even manually, result in being able to release the file?  It seems like checking the file version like this does is voiding the intended effect of clearing the dirty flag.  If not, how could a user escape the situation, short of deleting the file?&lt;/p&gt;

&lt;p&gt;Actually, as I think further, perhaps this is not a bug: I think the ability to clear the dirty flag manually is a debug/emergency recovery option?  Use of such a manual intervention tool could be expected to cause problems if it is not used in exactly the right situation.  So less than perfect handling of this case may not be something we need to fix.&lt;/p&gt;

&lt;p&gt;What were you trying to accomplish by clearing the dirty flag manually?&lt;/p&gt;</comment>
                            <comment id="126940" author="moea" created="Thu, 10 Sep 2015 16:54:44 +0000"  >&lt;p&gt;This bug was not preventing me from accomplishing anything in particular.  I reported this bug because I performed a sequence of valid operations and experienced an error message that did not seem appropriate for situation.  I&apos;m not asserting that the file should be released or not released; I agree that this would be a design level question. &lt;/p&gt;</comment>
                            <comment id="127042" author="panditadityashreesh" created="Fri, 11 Sep 2015 04:47:05 +0000"  >&lt;p&gt;If you archive the file again. Releasing the file works. I have added that in the test script. Can someone from design team review and post what should be the ideal behavior?&lt;/p&gt;</comment>
                            <comment id="127243" author="moea" created="Mon, 14 Sep 2015 16:36:25 +0000"  >&lt;p&gt;It&apos;s been a while since this bug has been reported, so it may take some time to rebuild our test environment.  &lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                            <customfield id="customfield_10890" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10040" key="com.atlassian.jira.plugin.system.customfieldtypes:labels">
                        <customfieldname>Epic</customfieldname>
                        <customfieldvalues>
                                        <label>client</label>
            <label>server</label>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10070" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Project</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10040"><![CDATA[HSM]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hzwzxj:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>16361</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10060" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Severity</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10022"><![CDATA[3]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        </customfields>
    </item>
</channel>
</rss>