From: Tom.Wang <Tom.Wang@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] readdir for striped dir
Date: Mon, 22 Mar 2010 19:09:39 -0400 [thread overview]
Message-ID: <4BA7F8B3.8050104@sun.com> (raw)
In CMD, one directory can be striped to several MDTs according to the
hash value of each entry (calculated by its name). Suppose we have N
MDTs and hash range is 0 to MAX_HASH. First server will keep records
with hashes [ 0 ... MAX_HASH / N - 1], second one with hashes [MAX_HASH
/ N ... 2 * MAX_HASH / N] and so on. Currently, it uses the same hash
policy with the one used on disk(ldiskfs/ext3 hash), so when reading
striped directory, the entries from different stripe objects can be
mapped on client side cache simply, actually this page cache is only
maintained in llite layer. But this bonding of CMD split-dir protocal
with on-disk hash seems not good, and it even brings more problems when
porting MDT to kdmu.
This dir-entry page cache should be moved to mdc layer, and each stripe
object will have its own page cache. It will need 2 lookups for locating
an entry in the page cache, first locating the stripe
objects(ll_stripe_offset will be added in ll_file_data to indicate the
stripe offset), then got the page by offset(f_pos) inside the
stripe_object. The entry page cache can even be organized as the favor
of different purposes, for example readdir-plus, dir-extent lock. Idealy
we can reuse the cl_page on mdc layer, but that might need object
layering on metadata stack. In the first step probably register some
page callback for mdc to manage the page cache.
next reply other threads:[~2010-03-22 23:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 23:09 Tom.Wang [this message]
2010-03-23 4:22 ` [Lustre-devel] readdir for striped dir Andreas Dilger
2010-03-23 11:29 ` Tom.Wang
2010-03-23 16:15 ` Nikita Danilov
2010-03-23 12:35 ` Tom.Wang
2010-03-23 18:23 ` Andreas Dilger
2010-03-23 19:14 ` Nikita Danilov
2010-03-24 22:23 ` Andreas Dilger
2010-03-25 16:26 ` Oleg Drokin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BA7F8B3.8050104@sun.com \
--to=tom.wang@sun.com \
--cc=lustre-devel@lists.lustre.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.