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