Gluster users - Aug 2017 - [Gluster-devel] How commonly applications make use of fadvise?

Hi all,

In a conversation between me, Milind and Csaba, Milind pointed out fadvise(2)
[1] and its potential benefits to Glusterfs' caching translators like
read-ahead etc. After discussing about it, we agreed that our performance
translators can leverage the hints to provide better performance. Now the
question is how commonly applications actually provide hints? Is it something
that is used quite frequently? If yes, we can think of implementing this in
glusterfs (probably kernel-fuse too?). If no, there is not much of an advantage
in spending our energies here. Your inputs will help us to prioritize this
feature.

[1] https://linux.die.net/man/2/fadvise

regards,
Raghavendra

Hi,

Both swift[1] and gluster-swift[2] calls posix_fadvise64()  with
POSIX_FADV_DONTNEED
right after calling fdatasync() or fsync(). This is only performed during
object PUT operation
(writing an object to disk) suggesting the kernel that the data written is
no longer needed
with the hopes that cached pages that are more useful are not discarded
instead.

[1]:
https://github.com/openstack/swift/blob/2105ad2a7f6e56cabea0e0b71c5cae94088fd597/swift/common/utils.py#L833
[2]:
https://github.com/gluster/gluster-swift/blob/master/gluster/swift/obj/diskfile.py#L300

On Fri, Aug 11, 2017 at 10:17 AM, Raghavendra Gowdappa <rgowdapp at
redhat.com>
wrote:
> Hi all,
>
> In a conversation between me, Milind and Csaba, Milind pointed out
> fadvise(2) [1] and its potential benefits to Glusterfs' caching
translators
> like read-ahead etc. After discussing about it, we agreed that our
> performance translators can leverage the hints to provide better
> performance. Now the question is how commonly applications actually provide
> hints? Is it something that is used quite frequently? If yes, we can think
> of implementing this in glusterfs (probably kernel-fuse too?). If no, there
> is not much of an advantage in spending our energies here. Your inputs will
> help us to prioritize this feature.
>
> [1] https://linux.die.net/man/2/fadvise
>
> regards,
> Raghavendra
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20170811/615885e0/attachment.html>

On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa
wrote:
> Hi all,
> 
> In a conversation between me, Milind and Csaba, Milind pointed out
> fadvise(2) [1] and its potential benefits to Glusterfs' caching
> translators like read-ahead etc. After discussing about it, we agreed
> that our performance translators can leverage the hints to provide
> better performance. Now the question is how commonly applications
> actually provide hints? Is it something that is used quite frequently?
> If yes, we can think of implementing this in glusterfs (probably
> kernel-fuse too?). If no, there is not much of an advantage in
> spending our energies here. Your inputs will help us to prioritize
> this feature.
If functionality like this is available, we would add support in
libgfapi.so as well. NFS-Ganesha is prepared for consuming this
(fsal_obj_ops->io_advise), so applications running on top of NFS will
benefit. I failed to see if the standard Samba/vfs can use it.

A quick check in QEMU does not suggest it is used by the block drivers.

I don't think Linux/FUSE supports fadvise though. So this is an
oppertunity for a Gluster developer to get their name in the Linux
kernel :-) Feature additions like this have been done before by us, and
we should continue where we can. It is a relatively easy entry for
contributing to the Linux kernel.
 
> [1] https://linux.die.net/man/2/fadvise
As well as local man-pages for fadvise64/posix_fadvise.

Showing that we have support for this, suggests that the filesystem
becomes more mature and gains advanced features. This should impress
users and might open up more interest for certain (HPC?) use-cases.

Thanks,
Niels

> 
> regards,
> Raghavendra
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel