[Gluster-devel] memory leaks

[Brent A Nelson]

On Thu, 8 Mar 2007, Amar S. Tumballi wrote:

> On Thu, Mar 08, 2007 at 12:52:35PM -0500, Brent A Nelson wrote:
>> volume server
>>   type protocol/server
>>   subvolumes share0 share1 share2 share3 share4 share5 share6 share7
>> share8 share9 share10 share11 share12 share13 share14 share15
>>   ...
>> end-volume
>
> you can't have more than one subvolumes in protocol/server xlator. The clustering
> ability is there only within cluster/{unify,stripe,afr} xlators.
>

Doesn't that just export multiple volumes from one server so the client 
can access them all? I use cluster/unify and cluster/afr on the client to 
cluster together the server's volumes, and it works (except for what 
appear to be memory leaks).  Also, the examples in the documentation show 
multiple subvolumes just as I am doing (e.g., the section "AFR Example 
in Clustered Mode"), so I assumed that was the proper way to do it.

Otherwise, you'd do a protocol/server (or maybe a separate glusterfsd?) 
for every export.  Unless, of course, it makes sense to put a cluster 
translator on the server, rather than the client...

>>
>> volume statprefetch
>>   type performance/stat-prefetch
>>   option cache-seconds 2
>>   subvolumes server
>> end-volume
>>
>> volume writebehind
>>   type performance/write-behind
>>   option aggregate-size 131072 # in bytes
>>   subvolumes statprefetch
>> end-volume
>>
>> volume readahead
>>   type performance/read-ahead
>>   option page-size 65536 ### in bytes
>>   option page-count 16 ### memory cache size is page-count x page-size per
>>   file#
>>   subvolumes writebehind
>> end-volume
>>
>> volume iot
>>   type performance/io-threads
>>   option thread-count 8
>>   subvolumes readahead
>> end-volume
>>
> no.. in server side, server should be the top most volume. and later, all other
> volumes should come.

Just to be clear, can you give me a proper basic example of a server 
exporting two disks, with all performance translators correctly 
configured? The documentation is lacking in this area...

> And about io-threads if you have used it in the client side,
> there is some work pending to make it run seemlessly (as few part of our code is
> not yet threadsafe). So, i advice you to run io-threads only on server.
>

Okay, will do.

>> Thanks,
>>
>
> I am working on read-ahead/memory leak issues now.. once found, will get back to you..
>
> Amar
>

Okay, great.

Thanks,

Brent