<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:14:18 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-8063] Fileset mount with automatic group lock</title>
                <link>https://jira.whamcloud.com/browse/LU-8063</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;Recently patch of fileset mount support has been merged into master&lt;br/&gt;
branch. That feature enables mounting sub-directories of Lustre&lt;br/&gt;
file system, which could be used as a way to isolate namespaces&lt;br/&gt;
between different groups. And the isolated namespaces and different&lt;br/&gt;
mount points natually imply that they might have different filesystem&lt;br/&gt;
semantics. That is why I am wondering whether fileset mount feature&lt;br/&gt;
can be combined with group lock feature.&lt;/p&gt;

&lt;p&gt;Group lock is a LDLM lock type which turns off LDLM locking on a file&lt;br/&gt;
for group members. In this way it avoids the LDLM lock overhead of&lt;br/&gt;
accessing the file. However, using group lock requires modification&lt;br/&gt;
of the application since an ioctl() needs to be called to get the&lt;br/&gt;
group lock. This is not convenient, since sometimes, it is just&lt;br/&gt;
impossible to modify the application. So these applications can&apos;t use&lt;br/&gt;
group lock to speed up performance even if the processes of the&lt;br/&gt;
application access the file in a way that won&apos;t overlap with each&lt;br/&gt;
other.&lt;/p&gt;

&lt;p&gt;Thus, a mount option of &quot;grouplock=$GID&quot; could be added to indicate&lt;br/&gt;
that any open() operation on that client also means acquiring a group&lt;br/&gt;
lock of that file. All the group members could share data efficiently&lt;br/&gt;
without LDLM lock overhead by mounting the file system with the same&lt;br/&gt;
group lock ID. And normal clients can still access the file if no&lt;br/&gt;
one is holding the group lock of it.&lt;/p&gt;

&lt;p&gt;The mount option of group lock is not suitable to be used on the top&lt;br/&gt;
directory of Lustre, because all of the other clients will be&lt;br/&gt;
affected. However, with fileset mount feature, a sub-directory of the&lt;br/&gt;
file system can be mounted with the mount option of group lock, thus&lt;br/&gt;
only a subtree will have that special behavior. And that subtree might&lt;br/&gt;
only be actively accessed by a few group members.&lt;/p&gt;

&lt;p&gt;Further more, currently, we don&apos;t have any way to avoid ldlm lock&lt;br/&gt;
latency of metadata access like group lock. But if we are able to&lt;br/&gt;
build similar mechanism to provide a file system semantics which is&lt;br/&gt;
less strict than POSIX, i.e. NFS-like interfaces or even local-&lt;br/&gt;
filesystem-like interfaces without any cache protection or&lt;br/&gt;
synchronization provided by LDLM lock, we could use it together with&lt;br/&gt;
fileset mount feature too. None-POSIX semantics might cause huge&lt;br/&gt;
performance improvement, especially for the weak points of Lustre&lt;br/&gt;
like small file I/O. And together with the scalabilty that Lustre&lt;br/&gt;
can provide, it will enable entirely new use cases.&lt;/p&gt;

&lt;p&gt;Anyway, I will push the patch that adds automatic group lock support&lt;br/&gt;
soon.&lt;/p&gt;</description>
                <environment></environment>
        <key id="36358">LU-8063</key>
            <summary>Fileset mount with automatic group lock</summary>
                <type id="2" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11311&amp;avatarType=issuetype">New Feature</type>
                                            <priority id="4" iconUrl="https://jira.whamcloud.com/images/icons/priorities/minor.svg">Minor</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="2">Won&apos;t Fix</resolution>
                                        <assignee username="lixi">Li Xi</assignee>
                                    <reporter username="lixi">Li Xi</reporter>
                        <labels>
                            <label>patch</label>
                    </labels>
                <created>Mon, 25 Apr 2016 08:41:18 +0000</created>
                <updated>Fri, 12 Jan 2018 02:19:33 +0000</updated>
                            <resolved>Fri, 12 Jan 2018 02:19:33 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>11</watches>
                                                                            <comments>
                            <comment id="149997" author="gerrit" created="Mon, 25 Apr 2016 08:46:21 +0000"  >&lt;p&gt;Li Xi (lixi@ddn.com) uploaded a new patch: &lt;a href=&quot;http://review.whamcloud.com/19760&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/19760&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-8063&quot; title=&quot;Fileset mount with automatic group lock&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-8063&quot;&gt;&lt;del&gt;LU-8063&lt;/del&gt;&lt;/a&gt; llite: add grouplock mount option&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 6b95068bbebd9cf76346fe2365d0d862390f7a4c&lt;/p&gt;</comment>
                            <comment id="150072" author="pjones" created="Mon, 25 Apr 2016 18:03:10 +0000"  >&lt;p&gt;Thanks Li Xi&lt;/p&gt;</comment>
                            <comment id="150501" author="adilger" created="Thu, 28 Apr 2016 19:31:13 +0000"  >&lt;p&gt;Before we land a patch like this, I think there needs to be a clear benefit to having it in the first place.&lt;/p&gt;

&lt;p&gt;Enabling group lock on every file in a subtree mount could potentially cause a lot of problems for applications running there, since it means that there will be no cache invalidation between clients, and writes from one client will not be seen by another client without an explicit sync() on the file.  It isn&apos;t even clear if closing the file will cause the data to be flushed or not.  Also, any files in this subtree may be permanently inaccessable to other clients that are not mounting with this same grouplock option, if one of the grouplock clients holds the file open, which will cause lock timeouts on the other clients and other potential problems.&lt;/p&gt;

&lt;p&gt;Since the main motivation for such a patch is performance due to reduced DLM locking, have you measured some performance improvement from using this patch?  If yes, what kind of workload was run to see this performance improvement, and is there some other way to get this improvement with the current DLM without the need to have explicit mount options for such subtrees?  That would benefit all Lustre clients, instead of the small subset that would be mounted with the grouplock option.&lt;/p&gt;</comment>
                            <comment id="150525" author="lixi" created="Fri, 29 Apr 2016 01:04:09 +0000"  >&lt;p&gt;I totally agree that we shouldn&apos;t merge this patch in a rush without fully&lt;br/&gt;
understanding the benefits and problems.&lt;/p&gt;

&lt;p&gt;We currently don&apos;t have any application which is using grouplock. I myself, is&lt;br/&gt;
wondering how much performance improvement could be achieved by using&lt;br/&gt;
grouplocks. It is not easy to make a clear conclusion because the performance&lt;br/&gt;
improvement is highly correlated with the workloads. That means, we can&apos;t use&lt;br/&gt;
any existing benchmark tools to test gouplock. The results of some bechmarks&lt;br/&gt;
might be disappointing (if, as I am expecting, LDLM is highly optimized).&lt;/p&gt;

&lt;p&gt;However, I do believe that there is some workloads which can be accelerated by&lt;br/&gt;
grouplock. A perfect place of using grouplock is I/O forwarding system or I/O&lt;br/&gt;
proxy, or any middle ware between acess nodes (or compute nodes) and Lustre&lt;br/&gt;
clients. Because Lustre is kind of wrapped by the middle ware, the potential&lt;br/&gt;
problems of grouplock can be avoided in many ways. And we are seeing more kinds&lt;br/&gt;
of middle wares in front of Lustre, including I/O forwarding systems, burst&lt;br/&gt;
buffers, hadoop, openstack, or even qemu. In these use cases, the I/O patterns&lt;br/&gt;
might not be traditional. And in order to better support those patterns, Lustre&lt;br/&gt;
could probably don&apos;t need to provide POSIX semantics. For example, if we want&lt;br/&gt;
to store KVM images on Lustre, we probaly don&apos;t need the data to be synced in&lt;br/&gt;
in real time between clients at all.&lt;/p&gt;

&lt;p&gt;Of course, those use cases are not traditional fields that Lustre is focusing&lt;br/&gt;
on. Lustre is doing great in HPC, but is used less in other fields. In my&lt;br/&gt;
opinion, being used by more users in more domains always bring benefits.&lt;/p&gt;

&lt;p&gt;Obviously, grouplock won&apos;t be useful for all of those cases. Its use cases&lt;br/&gt;
might be very limited. That is why I am looking for other mechanisms, such as&lt;br/&gt;
fscache/cachefiles support for Lustre. And Lustre with fscache seems also&lt;br/&gt;
limited, which can only be used as read cache of dataas far as I can see. I am&lt;br/&gt;
wondering whether there is any way to build a writable cache level on Lustre&lt;br/&gt;
client which is not necessarily be based on memory pages, yet can cache both&lt;br/&gt;
the metadata and data of a Lustre subtree, and buffer all the modifications in&lt;br/&gt;
that subtree. That might be more helpful for some use cases. And it is still&lt;br/&gt;
worth to do so even if semantics or interfaces of Lustre need to be changed.&lt;/p&gt;</comment>
                            <comment id="212601" author="adilger" created="Thu, 2 Nov 2017 01:24:08 +0000"  >&lt;p&gt;Li Xi, is this work replaced by the LCOC/PCC feature?  Otherwise, I think that using group lock is not really the right way to fix this problem.  Group lock still needs to get a DLM lock from the server, so it only makes a difference when there are multiple clients accessing the same file, to avoid lock contention. &lt;/p&gt;</comment>
                            <comment id="218067" author="lixi" created="Fri, 12 Jan 2018 02:18:54 +0000"  >&lt;p&gt;Hi Andreas,&lt;/p&gt;

&lt;p&gt;Yeah, I think PCC might be better solution for some of the use cases mentioned in this ticket. And Rreadonly-PCC uses grouplock. So I am closing this ticket.&lt;/p&gt;

&lt;p&gt;It was good to discuss though. &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; Thanks!&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>Fri, 29 Apr 2016 08:41:18 +0000</customfieldvalue>

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

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10493" key="com.atlassian.jira.plugin.system.customfieldtypes:datepicker">
                        <customfieldname>Start date</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Mon, 25 Apr 2016 08:41:18 +0000</customfieldvalue>

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