[Gluster-devel] How commonly applications make use of fadvise?
Niels de Vos
ndevos at redhat.com
Fri Aug 11 12:33:07 UTC 2017
On Fri, Aug 11, 2017 at 05:50:47PM +0530, Ravishankar N 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)  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. :-)
Thanks for checking! If that is the case, we need a good use-case to add
a fadvise function pointer to the file_operations. It is not impossible
to convince the Linux VFS developers, but it would not be as trivial as
adding it to FUSE only (but that requires the VFS infrastructure to be
> > >  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
More information about the Gluster-devel