<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:24:02 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-2298] Changelog does not register file modifications</title>
                <link>https://jira.whamcloud.com/browse/LU-2298</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;The problem comes when some tools try to detect changes in files thanks to the changelog functionality. The changelog is regularly read (every second) from a registered client (actually the only one registered) and then the records are acknowledged so they can be deleted in the changelog.&lt;/p&gt;

&lt;p&gt;At the same time, on another Lustre client we run the next process every second on a file:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Open a file&lt;/li&gt;
	&lt;li&gt;Write of 1MB&lt;/li&gt;
	&lt;li&gt;Sync file&lt;/li&gt;
	&lt;li&gt;Close file&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;We would expect to see MTIME or OPEN or CREATE in the changelog but we don&apos;t see anything. The only way to see an MTIME event is to specify a SETATTR operation which provokes the modification on the MDT.&lt;/p&gt;

&lt;p&gt;Another example of this pattern can be seen with the differences between cat and touch commands. If we run &quot;cat whatever &amp;gt;&amp;gt; my_lustre_file&quot;, the MDT will never see the modification. If we run &quot;touch my_lustre_file&quot;, then we&apos;ll see an MTIME event as touch command will specifically do SETATTR.&lt;/p&gt;

&lt;p&gt;It is normal not to see any modification while the write is being done on the OSTs but my question is: shouldn&apos;t MDT see the modification once the file is closed? Because if applications must do a SETATTR then I&apos;m not sure that changelog can be used to detect any kind of event.&lt;/p&gt;

&lt;p&gt;Description of the reproducer:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;On the MDT:&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;root@hsm6 ~&amp;#93;&lt;/span&gt;# cat /proc/fs/lustre/mdd/hsmfs-MDT0000/changelog_users &lt;br/&gt;
current index: 29724&lt;br/&gt;
ID    index&lt;br/&gt;
cl1   29723&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;root@hsm6 ~&amp;#93;&lt;/span&gt;# cat /proc/fs/lustre/mdd/hsmfs-MDT0000/changelog_mask &lt;br/&gt;
MARK CREAT MKDIR HLINK SLINK MKNOD UNLNK RMDIR RNMFM RNMTO OPEN CLOSE IOCTL TRUNC SATTR XATTR HSM MTIME CTIME&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;On the changelog reader and while the write process is being run every second on another client:&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;&amp;gt;&amp;gt;&amp;gt;lfs changelog hsmfs-MDT0000&lt;br/&gt;
29723 00MARK  15:07:01.651522750 2012.11.07 0x0 t=&lt;span class=&quot;error&quot;&gt;&amp;#91;0x40001:0x0:0x0&amp;#93;&lt;/span&gt; p=&lt;span class=&quot;error&quot;&gt;&amp;#91;0:0x0:0x0&amp;#93;&lt;/span&gt; mdd_obd-hsmfs-MDT0000&lt;/p&gt;

&lt;p&gt;&amp;gt;&amp;gt;&amp;gt;lfs changelog_clear hsmfs-MDT0000 cl1 29723&lt;/p&gt;

&lt;p&gt;&amp;gt;&amp;gt;&amp;gt;lfs changelog hsmfs-MDT0000&lt;br/&gt;
29724 00MARK  15:07:07.399483862 2012.11.07 0x0 t=&lt;span class=&quot;error&quot;&gt;&amp;#91;0x40001:0x0:0x0&amp;#93;&lt;/span&gt; p=&lt;span class=&quot;error&quot;&gt;&amp;#91;0:0x0:0x0&amp;#93;&lt;/span&gt; mdd_obd-hsmfs-MDT0000&lt;/p&gt;

&lt;p&gt;And the changelog will always remain in the last entry until the client acknowledges an entry (having then another MARK event).&lt;/p&gt;</description>
                <environment></environment>
        <key id="16616">LU-2298</key>
            <summary>Changelog does not register file modifications</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.whamcloud.com/images/icons/priorities/major.svg">Major</priority>
                        <status id="5" iconUrl="https://jira.whamcloud.com/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="1">Fixed</resolution>
                                        <assignee username="niu">Niu Yawei</assignee>
                                    <reporter username="dmoreno">Diego Moreno</reporter>
                        <labels>
                    </labels>
                <created>Wed, 7 Nov 2012 10:54:37 +0000</created>
                <updated>Tue, 18 Jul 2017 01:58:24 +0000</updated>
                            <resolved>Tue, 18 Jul 2017 01:58:24 +0000</resolved>
                                    <version>Lustre 2.1.3</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>19</watches>
                                                                            <comments>
                            <comment id="47577" author="pjones" created="Thu, 8 Nov 2012 09:23:04 +0000"  >&lt;p&gt;Niu&lt;/p&gt;

&lt;p&gt;Could you please look into this one?&lt;/p&gt;

&lt;p&gt;Thanks&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="47620" author="niu" created="Thu, 8 Nov 2012 22:47:15 +0000"  >&lt;blockquote&gt;
&lt;p&gt;It is normal not to see any modification while the write is being done on the OSTs but my question is: shouldn&apos;t MDT see the modification once the file is closed? Because if applications must do a SETATTR then I&apos;m not sure that changelog can be used to detect any kind of event.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;Without SOM (size on MDS), the MTIME is stored on OSTs, and MDT will not see the modification on file close neither (we only update ATIME on flie close). So, with current design, I think it&apos;s not a good idea to detect file data changes by changelog.&lt;/p&gt;</comment>
                            <comment id="47631" author="jcl" created="Fri, 9 Nov 2012 05:10:21 +0000"  >&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;May be it is time to finish SOM &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/li&gt;
	&lt;li&gt;if changelog is not good to detect file data changes, how can we ?&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="48278" author="leibovici-cea" created="Thu, 22 Nov 2012 05:43:28 +0000"  >&lt;p&gt;Looking at the changelog code, I suspect a matter in the changelog mechanism&lt;br/&gt;
in the mdd_changelog_data_store() function (mdd_object.c, line 1362 in Lustre 2.1).&lt;br/&gt;
Indeed, all &quot;time&quot; events are lost as long as there still ANY other record related to the same file in the log.&lt;br/&gt;
I understand this avoids &quot;*TIME&quot; records storms in the log.&lt;br/&gt;
So I&apos;d suggest replacing the current test by: don&apos;t log the xTIME event if there is still a *TIME record related to the same file in the log.&lt;/p&gt;

&lt;p&gt;Thomas&lt;/p&gt;</comment>
                            <comment id="48519" author="niu" created="Thu, 29 Nov 2012 01:05:43 +0000"  >&lt;blockquote&gt;
&lt;p&gt;May be it is time to finish SOM&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Probably. &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;if changelog is not good to detect file data changes, how can we ?&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;I&apos;m not sure, probably the tool can check the file itself according the open/close record in changelog?&lt;/p&gt;</comment>
                            <comment id="48793" author="dmoreno" created="Wed, 5 Dec 2012 07:26:12 +0000"  >&lt;p&gt;Niu, &lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;What about the proposal by Thomas Leibovici discarding TIME events only when another TIME event related with the file is present? Actually I&apos;m not sure that these TIME events are being sent from the OSTs to the MDT. What&apos;s the behavior between the OSTs and MDT&apos;s ChangeLog when a client is writing on an OST?&lt;/li&gt;
&lt;/ul&gt;


&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;What do you mean by checking the open/close in the changelog? At least for lustre 2.1 there is no CLOSE event in the changelog when we close the file. Are we supposed to see it?&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="48806" author="niu" created="Wed, 5 Dec 2012 09:16:51 +0000"  >&lt;p&gt;Hi, Diego&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;What about the proposal by Thomas Leibovici discarding TIME events only when another TIME event related with the file is present? Actually I&apos;m not sure that these TIME events are being sent from the OSTs to the MDT. What&apos;s the behavior between the OSTs and MDT&apos;s ChangeLog when a client is writing on an OST?&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;As far as I know, OSTs don&apos;t send the TIME to MDT, and there isn&apos;t any changelogs on OSTs. When client writing to OST, only the objects on OST is written, no MDT involved.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;What do you mean by checking the open/close in the changelog? At least for lustre 2.1 there is no CLOSE event in the changelog when we close the file. Are we supposed to see it?&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Ah, you are right, CL_CLOSE (close event) isn&apos;t recorded in 2.1.&lt;/p&gt;

&lt;p&gt;I&apos;m not sure if it&apos;s worth improving the changelog to make it achieve your requirement, since I beleive that could have been resolved in HSM project. How about detecting the file changes in user level (for lustre 2.1)? for example, scanning the file changes by a background daemon?&lt;/p&gt;</comment>
                            <comment id="54547" author="vitaly_fertman" created="Thu, 21 Mar 2013 09:15:27 +0000"  >&lt;p&gt;CLOSE event could be optionally logged since lustre 2.2, landed as &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-579&quot; title=&quot;add CLOSE event into changelog&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-579&quot;&gt;&lt;del&gt;LU-579&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="54789" author="nrutman" created="Mon, 25 Mar 2013 20:07:53 +0000"  >&lt;p&gt;mdt_mfd_close seems to filter out mtime updates from the close for SOM.&lt;/p&gt;</comment>
                            <comment id="54790" author="nrutman" created="Mon, 25 Mar 2013 20:08:32 +0000"  >&lt;p&gt;Thomas, what does Robinhood do to detect mtime updates?&lt;/p&gt;</comment>
                            <comment id="54800" author="nrutman" created="Mon, 25 Mar 2013 20:56:16 +0000"  >&lt;p&gt;Note &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-579&quot; title=&quot;add CLOSE event into changelog&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-579&quot;&gt;&lt;del&gt;LU-579&lt;/del&gt;&lt;/a&gt; added CL_CLOSE events, landed for Lustre 2.2.  However, looking at current Master, it seems to have been removed.&lt;/p&gt;</comment>
                            <comment id="54825" author="leibovici-cea" created="Tue, 26 Mar 2013 07:56:22 +0000"  >&lt;p&gt;Since this LU was opened, robinhood now relies on both MTIME and CLOSE events to detect file modifications (Lustre 2.2+ and robinhood 2.4.1).&lt;br/&gt;
Tracking CLOSE events fixes the issue Diego Moreno reported.&lt;/p&gt;</comment>
                            <comment id="54826" author="vitaly_fertman" created="Tue, 26 Mar 2013 08:16:50 +0000"  >&lt;p&gt;Nathan Rutman added a comment - 25/Mar/13 8:07 PM&lt;br/&gt;
&amp;gt; mdt_mfd_close seems to filter out mtime updates from the close for SOM.&lt;/p&gt;

&lt;p&gt;wrong, SOM is not related here, it did not change the original logic. this filtering existed since the beginning.&lt;/p&gt;</comment>
                            <comment id="54827" author="vitaly_fertman" created="Tue, 26 Mar 2013 08:19:33 +0000"  >&lt;p&gt;Nathan Rutman added a comment - 25/Mar/13 8:56 PM&lt;br/&gt;
&amp;gt; Note &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-579&quot; title=&quot;add CLOSE event into changelog&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-579&quot;&gt;&lt;del&gt;LU-579&lt;/del&gt;&lt;/a&gt; added CL_CLOSE events, landed for Lustre 2.2.&lt;br/&gt;
&amp;gt; However, looking at current Master, it seems to have been removed.&lt;/p&gt;

&lt;p&gt;afaics, it is still in place, otherwise sanity test 160 would not work.&lt;/p&gt;</comment>
                            <comment id="55062" author="nrutman" created="Thu, 28 Mar 2013 23:15:29 +0000"  >&lt;p&gt;From Thomas:&lt;/p&gt;

&lt;p&gt;I made a few tests on Lustre 2.1 and Lustre 2.4 (master) and I get the same behavior:&lt;br/&gt;
I seams that MTIME event is raised on open(O_TRUNC) but not for appending.&lt;/p&gt;

&lt;p&gt;echo 1 &amp;gt; /mnt/lustre/dir/test&lt;br/&gt;
lfs changelog lustre ; lfs changelog_clear lustre cl1 0&lt;/p&gt;

&lt;p&gt;55585 01CREAT 07:58:30.990467019 2013.03.27 0x0 t=&lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000400:0x73a6:0x0&amp;#93;&lt;/span&gt; p=&lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000400:0x73a5:0x0&amp;#93;&lt;/span&gt; test&lt;/p&gt;

&lt;p&gt;echo 1 &amp;gt; /mnt/lustre/dir/test&lt;br/&gt;
lfs changelog lustre ; lfs changelog_clear lustre cl1 0&lt;/p&gt;

&lt;p&gt;55586 17MTIME 07:58:36.765666783 2013.03.27 0x6 t=&lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000400:0x73a6:0x0&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;echo 1 &amp;gt;&amp;gt; /mnt/lustre/dir/test&lt;br/&gt;
lfs changelog lustre ; lfs changelog_clear lustre cl1 0&lt;/p&gt;

&lt;p&gt;&amp;lt;nothing&amp;gt;&lt;/p&gt;

&lt;p&gt;dd if=/dev/urandom of=/mnt/lustre/dir/test bs=1k count=50000&lt;br/&gt;
lfs changelog lustre ; lfs changelog_clear lustre cl1 0&lt;/p&gt;

&lt;p&gt;55587 17MTIME 07:58:49.788543052 2013.03.27 0x6 t=&lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000400:0x73a6:0x0&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;dd if=/dev/urandom of=/mnt/lustre/dir/test bs=1k count=50000 conv=notrunc&lt;br/&gt;
lfs changelog lustre ; lfs changelog_clear lustre cl1 0&lt;/p&gt;

&lt;p&gt;&amp;lt;nothing&amp;gt;&lt;/p&gt;</comment>
                            <comment id="55460" author="leibovici-cea" created="Thu, 4 Apr 2013 07:19:24 +0000"  >&lt;p&gt;Notice: we get CL_CLOSE for the &quot;nothing&quot; cases in Lustre 2.2 and later.&lt;br/&gt;
So handling the CL_CLOSE record is a suitable solution for these versions.&lt;/p&gt;

&lt;p&gt;The issue of Diego (also reported by James Silva, LLNL) is the robinhood DB do not reflect the actual file sizes&lt;br/&gt;
because it is never aware of the file change (with Lustre 2.1):&lt;br/&gt;
In Lustre 2.1, CL_CLOSE is not implemented and MTIME event is not triggered&lt;br/&gt;
in the modification cases I stated previously.&lt;/p&gt;</comment>
                            <comment id="55462" author="dmoreno" created="Thu, 4 Apr 2013 07:57:10 +0000"  >&lt;p&gt;I do agree with Thomas that managing CLOSE events should be enough for Robinhood. Concerning the MTIME event, I think it&apos;s hard for users or applications reading changelog to rely on this event because, as Nathan already commented, you cannot see MTIME in case of append to an existing file.&lt;/p&gt;</comment>
                            <comment id="60051" author="spitzcor" created="Wed, 5 Jun 2013 18:14:44 +0000"  >&lt;p&gt;It seems that TRUNC events are not raised at all.  Should there be a separate ticket created for that?&lt;/p&gt;</comment>
                            <comment id="143522" author="simmonsja" created="Wed, 24 Feb 2016 14:48:44 +0000"  >&lt;p&gt;Is this still true?&lt;/p&gt;</comment>
                            <comment id="202417" author="niu" created="Tue, 18 Jul 2017 01:58:24 +0000"  >&lt;p&gt;CLOSE event has been logged since 2.2, it can satisfy customer&apos;s requirement. Close this old 2.1 issue.&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_10490" key="com.atlassian.jira.plugin.system.customfieldtypes:datepicker">
                        <customfieldname>End date</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 24 Feb 2016 10:54:37 +0000</customfieldvalue>

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

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>5491</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>
                                                                                                                        <customfield id="customfield_10493" key="com.atlassian.jira.plugin.system.customfieldtypes:datepicker">
                        <customfieldname>Start date</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 7 Nov 2012 10:54:37 +0000</customfieldvalue>

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