On Fri, Aug 11, 2017 at 5:50 PM, Ravishankar N <[email protected]> wrote:
> > > On 08/11/2017 04:51 PM, Niels de Vos wrote: > >> On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa wrote: >> >>> Hi all, >>> >>> In a conversation between me, Milind and Csaba, Milind pointed out >>> fadvise(2) [1] and its potential benefits to Glusterfs' caching >>> translators like read-ahead etc. After discussing about it, we agreed >>> that our performance translators can leverage the hints to provide >>> better performance. Now the question is how commonly applications >>> actually provide hints? Is it something that is used quite frequently? >>> If yes, we can think of implementing this in glusterfs (probably >>> kernel-fuse too?). If no, there is not much of an advantage in >>> spending our energies here. Your inputs will help us to prioritize >>> this feature. >>> >> If functionality like this is available, we would add support in >> libgfapi.so as well. NFS-Ganesha is prepared for consuming this >> (fsal_obj_ops->io_advise), so applications running on top of NFS will >> benefit. I failed to see if the standard Samba/vfs can use it. >> >> A quick check in QEMU does not suggest it is used by the block drivers. >> >> I don't think Linux/FUSE supports fadvise though. So this is an >> oppertunity for a Gluster developer to get their name in the Linux >> kernel :-) Feature additions like this have been done before by us, and >> we should continue where we can. It is a relatively easy entry for >> contributing to the Linux kernel. >> > > 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. :-) > That's correct. file_operations don't have fadvise and hence exposing this to underlying filesystems would require adding this member. > Regards, > Ravi > > >> >>> [1] https://linux.die.net/man/2/fadvise >>> >> As well as local man-pages for fadvise64/posix_fadvise. >> >> Showing that we have support for this, suggests that the filesystem >> becomes more mature and gains advanced features. This should impress >> users and might open up more interest for certain (HPC?) use-cases. >> >> Thanks, >> Niels >> >> >> regards, >>> Raghavendra >>> _______________________________________________ >>> Gluster-devel mailing list >>> [email protected] >>> http://lists.gluster.org/mailman/listinfo/gluster-devel >>> >> _______________________________________________ >> Gluster-devel mailing list >> [email protected] >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > > _______________________________________________ > 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
