[Lustre-devel] readdir for striped dir
Tom.Wang
Tom.Wang at Sun.COM
Tue Mar 23 05:35:53 PDT 2010
Nikita Danilov wrote:
> On 23 March 2010 14:29, Tom.Wang <Tom.Wang at sun.com> wrote:
>
>> Hello,
>>
>
> Hello,
>
> [...]
>
>
>> LMV will use new hash function to select stripe object (mdc), which could be
>> independent with the one
>> used in the storage. In mdc level, it just need to map the entries of each
>> dir stripe object in the cache,
>> we can index the cache in anyway as we want, probably hash order (as the
>> server storage) is a good choice,
>> because client can easily find and cancel the pages by the hash in later
>> dir-extent lock. Note: Even in this case,
>> client does not need to know server hash scheme at all, since server will
>> set the hash-offset of these pages, client just
>> need to put these pages on the cache by hash-offset.
>> Currently, the cache will only be touched by readdir. If the cache will be
>> used by readdir-plus later, i.e. we need locate
>> the entry by name, then client must use the same hash as the server storage,
>> but server will tell client which hash function
>> it use. Yes, different hash per dirstripe should not be a problem here.
>>
>
> If I understand correctly, the scheme has an advantage of cleaner
> solution for readdir scalability than "hash adjust" hack of CMD3 (see
> comment in lmv/lmv_obd.c:lmv_readpage()). The problem, to remind, is
> that if a number of clients readdir the same split directory, they all
> hammer the same servers one after another, negating the advantages of
> meta-data clustering. The solution is to cyclically shift hash space
> by an offset depending on the client, so that clients load servers
> uniformly. With 2-level hashing, this shifting can be done entirely
> within new LMV hash function.
>
Yes, in this case, these clients should start from different
stripe-offset in
readdir.
Thanks
Wangdi
>
>> Thanks
>> WangDi
>>
>
> Thank you,
> Nikita.
>
More information about the lustre-devel
mailing list