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

[Raghavendra G]

On Fri, Aug 11, 2017 at 5:50 PM, Ravishankar N <ravishankar at redhat.com>
wrote:

>
>
> 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) [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.
>>
>
> 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.


> Regards,
> Ravi
>
>
>>
>>> [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
>>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170818/70e32dfd/attachment.html>