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

[Raghavendra G]

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-devel/attachments/20170821/013f2456/attachment.html>