On 02/03/2016 11:34 AM, Venky Shankar wrote:
On Wed, Feb 03, 2016 at 09:24:06AM -0500, Jeff Darcy wrote:
Problem is with workloads which know the files that need to be read
without readdir, like hyperlinks (webserver), swift objects etc. These
are two I know of which will have this problem, which can't be improved
because we don't have metadata, data co-located. I have been trying to
think of a solution for past few days. Nothing good is coming up :-/
In those cases, caching (at the MDS) would certainly help a lot. Some
variation of the compounding infrastructure under development for Samba
etc. might also apply, since this really is a compound operation.
When a client is done modifying a file, MDS would refresh it's size, mtime
attributes by fetching it from the DS. As part of this refresh, DS could
additionally send back the content if the file size falls in range, with
MDS persisting it, sending it back for subsequent lookup calls as it does
now. The content (on MDS) can be zapped once the file size crosses the
defined limit.
I like the idea. However the memory implications of maintaining content
in MDS is something to watch out for. quick-read is interested in files
of size 64k by default and with a reasonable number of files in that
range, we might end up consuming significant memory with this scheme.
-Vijay
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
