On Sat, Aug 19, 2017 at 4:27 PM, Csaba Henk <chenk@xxxxxxxxxx> wrote:
Hi Niels,
On Fri, Aug 11, 2017 at 2:33 PM, Niels de Vos <ndevos@xxxxxxxxxx> 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@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
Raghavendra G
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel