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