[Gluster-devel] How namespace works in mainline-2.5?

Anand Babu Periasamy ab at gnu.org.in
Fri Jun 22 10:12:10 UTC 2007


Dale, your assumptions are correct. Here is more info..

PREVIOUS DESIGN:
GlusterFS/unify will parallely query every sub-volume (brick) in the
cluster. The brick with the file responds with a file descriptor
successfully. This model is fast enough and simple.

NEW DESIGN:
GlusterFS/unify uses a cache to lookup the name space (to find where
a file is located). Though it takes an extra call before open, it
minimizes lookup operations. There are also other reasons why we
implemented name space cache and made it mandatory.
 * GlusterFS can avoid creation of files that already exist on a
   failed brick (temporarily down). 
 * Rarely some tools use inodes instead of file names. GlusterFS
   issues globally unique inodes consistently through the cache.

Cache is stored on a regular POSIX volume. It can be local or remote
or even over AFR'd remote volume. Having a cache volume remotely is
better because, the cache is shared across all the clients. Remember
it is just a cache. If you delete this cache directory, it will
rebuild itself transparently.

--
Anand Babu Periasamy

Dale Dude writes:
> Im giving input even though Im not positive. The namespace volume is
> needed because all the files/dirs are created there. Files being 0
> bytes. It seems to be used as the lookup "database" for a set of
> volumes. So the space requirements are low and I dont think its
> disposable. I believe they will be using this to keep the AFR
> volumes in sync.
> 
> Regards,
> Dale
> 
> Brent A Nelson wrote:
>> On Thu, 21 Jun 2007, Dale Dude wrote:
>>
>>> As for the doc/example...I see the cluster-client.vol was fixed,
>>> but the bricks-ns isnt configured in any of the
>>> cluster-server#.vol files.
>>>
>>
>> Speaking of which, what are the requirements/recommendations for
>> the namespace cache volume? How big should it be? Any special
>> considerations if we're targetting fault-tolerance (e.g., RAID or
>> AFR underneath), or is it truly disposable?
>>
>> Thanks,
>>
>> Brent
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel

-- 
Anand Babu
GPG Key ID: 0x62E15A31
Blog [http://ab.freeshell.org]
The GNU Operating System [http://www.gnu.org]








More information about the Gluster-devel mailing list