From: Alex Zhuravlev <Alex.Zhuravlev@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] some thoughts on COS
Date: Mon, 30 Jun 2008 12:10:17 +0400 [thread overview]
Message-ID: <486894E9.1030104@sun.com> (raw)
In-Reply-To: <C46FF0A8.591A%peter.braam@sun.com>
Hi,
all access to an object can be broken into 3 phases:
1) lock is acquired and used to modify data, no concurrent
access as data is inconsistent
2) data is consistent, but uncommitted; thus same client can
access data, others can not
3) all clients can access data
it'd make sense to have same lock handle for (1) and (2) as it
is stored in request and later used to release lock up on commit.
(1) and (3) are clear - this is just lock acquired and lock released.
what if we introduce new lock state (bit, whatever) compatible with
one client (some tag in the lock) and incompatible with others?
in order to keep same lock handle we convert lock (1) into lock (2).
conversion isn't a new conception, we did it before.
then, regular create would look like:
1) lockh = enqueue(PW, clientid); // clientid is stored in the lock
2) object creation; directory modification
3) ptlrpc_save_lock(req, lockh)
convert(lockh, PW, OWN)
...
4) commit
lock_decref(lockh, OWN)
also, we'd have to register blocking AST in MDS in order to intercept
collision when one client tries to access data modified by another one.
from that handling we could initiate or schedule sync commit.
this looks like a quite simple conception. but it's far from being
optimal - what if one client does thousand creations, we'll end with
thousand OWN locks, while to prevent alien access we need a single one.
couple ideas can be used here:
1) cache locks on the MDS side as per Nikita's suggestion
2) drop all OWN locks from completion AST
please comments, thoughts?
thanks, Alex
next prev parent reply other threads:[~2008-06-30 8:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-05 12:27 [Lustre-devel] some thoughts on COS Alex Zhuravlev
2008-06-07 14:00 ` Peter Braam
2008-06-30 8:10 ` Alex Zhuravlev [this message]
2008-06-30 10:11 ` Nikita Danilov
2008-06-30 11:04 ` Alex Zhuravlev
2008-06-30 14:00 ` Peter Braam
2008-06-10 18:50 ` Alexander Zarochentsev
2008-06-10 21:24 ` Peter Braam
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=486894E9.1030104@sun.com \
--to=alex.zhuravlev@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.