Details
-
New Feature
-
Resolution: Won't Fix
-
Minor
-
None
-
None
-
9223372036854775807
Description
Recently patch of fileset mount support has been merged into master
branch. That feature enables mounting sub-directories of Lustre
file system, which could be used as a way to isolate namespaces
between different groups. And the isolated namespaces and different
mount points natually imply that they might have different filesystem
semantics. That is why I am wondering whether fileset mount feature
can be combined with group lock feature.
Group lock is a LDLM lock type which turns off LDLM locking on a file
for group members. In this way it avoids the LDLM lock overhead of
accessing the file. However, using group lock requires modification
of the application since an ioctl() needs to be called to get the
group lock. This is not convenient, since sometimes, it is just
impossible to modify the application. So these applications can't use
group lock to speed up performance even if the processes of the
application access the file in a way that won't overlap with each
other.
Thus, a mount option of "grouplock=$GID" could be added to indicate
that any open() operation on that client also means acquiring a group
lock of that file. All the group members could share data efficiently
without LDLM lock overhead by mounting the file system with the same
group lock ID. And normal clients can still access the file if no
one is holding the group lock of it.
The mount option of group lock is not suitable to be used on the top
directory of Lustre, because all of the other clients will be
affected. However, with fileset mount feature, a sub-directory of the
file system can be mounted with the mount option of group lock, thus
only a subtree will have that special behavior. And that subtree might
only be actively accessed by a few group members.
Further more, currently, we don't have any way to avoid ldlm lock
latency of metadata access like group lock. But if we are able to
build similar mechanism to provide a file system semantics which is
less strict than POSIX, i.e. NFS-like interfaces or even local-
filesystem-like interfaces without any cache protection or
synchronization provided by LDLM lock, we could use it together with
fileset mount feature too. None-POSIX semantics might cause huge
performance improvement, especially for the weak points of Lustre
like small file I/O. And together with the scalabilty that Lustre
can provide, it will enable entirely new use cases.
Anyway, I will push the patch that adds automatic group lock support
soon.