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

Csaba Henk chenk at redhat.com
Sat Aug 19 10:57:12 UTC 2017

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.


More information about the Gluster-devel mailing list