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

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

Niels

> 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
>

Hi Niels,

On Fri, Aug 11, 2017 at 2:33 PM, Niels de Vos <ndevos at redhat.com>
wrote:
> On Fri, Aug 11, 2017 at 05:50:47PM +0530, Ravishankar N wrote:
[...]
>> 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
> there).
Well, question is: are strategies of the caching xlators' mapping well to
the POSIX_FADV_* hint set? Would an application that might run on
a GlusterFS storage backend use fadvise(2) anyway or would fadvise calls
be added particularly to optimize the GlusterFS backed scenario?

Because if usage of fadvise were specifically to address the GlusterFS
backend -- either because of specifc semantic or specific behavior --, then
I don't see much point in force-fitting this kind of tuning into the fadvise
syscall. We can just as well operate then via xattrs.

Csaba

On Sat, Aug 19, 2017 at 4:27 PM, Csaba Henk <chenk at redhat.com> wrote:
> Hi Niels,
>
> On Fri, Aug 11, 2017 at 2:33 PM, Niels de Vos <ndevos at redhat.com>
wrote:
> > On Fri, Aug 11, 2017 at 05:50:47PM +0530, Ravishankar N wrote:
> [...]
> >> 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
> > there).
>
> Well, question is: are strategies of the caching xlators' mapping well
to
> the POSIX_FADV_* hint set? Would an application that might run on
> a GlusterFS storage backend use fadvise(2) anyway or would fadvise calls
> be added particularly to optimize the GlusterFS backed scenario?
>
+Pranith, +ravi.

If I am not wrong, afr too has strategies like eager-locking if writes are
sequential. Wondering whether afr can benefit from a feature like this.

> Because if usage of fadvise were specifically to address the GlusterFS
> backend -- either because of specifc semantic or specific behavior --, then
> I don't see much point in force-fitting this kind of tuning into the
> fadvise
> syscall. We can just as well operate then via xattrs.
>
> Csaba
> _______________________________________________
> 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-users/attachments/20170821/013f2456/attachment.html>