[Gluster-devel] How commonly applications make use of fadvise?
raghavendra at gluster.com
Fri Aug 18 10:32:16 UTC 2017
On Fri, Aug 11, 2017 at 5:50 PM, Ravishankar N <ravishankar at redhat.com>
> On 08/11/2017 04:51 PM, Niels de Vos wrote:
>> 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)  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.
> To me it looks like fadvise (mm/fadvise.c) affects only the linux page
> cache behavior and is decoupled from the filesystem itself. What this means
> for fuse is that the 'advise' is only to the content that the fuse kernel
> module has stored in that machine's page cache. Exposing it as a FOP would
> likely involve adding a new fop to struct file_operations that is common
> across the entire VFS and likely won't fly with the kernel folks. I could
> be wrong in understanding all of this. :-)
That's correct. file_operations don't have fadvise and hence exposing this
to underlying filesystems would require adding this member.
>>>  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.
>>> Gluster-devel mailing list
>>> Gluster-devel at gluster.org
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
> Gluster-devel mailing list
> Gluster-devel at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel