[Gluster-devel] regarding GF_CONTENT_KEY and dht2 - perf with small files

[Vijay Bellur]

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