From: Patrick Farrell <paf@cray.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] Lock ahead - Possible change
Date: Fri, 10 Jul 2015 11:14:45 -0500 [thread overview]
Message-ID: <559FEF75.4080103@cray.com> (raw)
Good morning,
I am reluctant to make further changes to lock ahead at this point when
it is ready and pending review, but I wanted to float an idea to see if
it would likely meet acceptance. (I am primarily asking Jinshan and
Andreas, who have been involved from the beginning.)
Currently, lock ahead requests are asynchronous, and, because of that,
non-blocking. What about the possibility of also allowing blocking,
*synchronous* requests via the same API?
This is intended as a way for a client to make a blocking lock request
on a specific region of a file, rather than the whole file by taking a
group lock as is currently the only option.
This would not be used for my immediate goal of enhancing strided
writing performance with lock ahead itself, but might be handy in other
situations and is a pretty minor change to the API. (Just allow
blocking requests and make them synchronous, rather than not allowing
them as is the case now.)
I still think I will push this out to a future enhancement of the
feature rather than integrate it into the current patch.
Thoughts? Objections?
I admit that this expansion of the API is making me question 'lock
ahead' as the name for the API itself, rather than a particular usage of
it. Perhaps that's not a direction we want to go, or perhaps we should
rename the API. (Suggestions encouraged)
- Patrick Farrell
next reply other threads:[~2015-07-10 16:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 16:14 Patrick Farrell [this message]
2015-07-29 4:53 ` [lustre-devel] Lock ahead - Possible change Dilger, Andreas
2015-07-31 3:54 ` Drokin, Oleg
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=559FEF75.4080103@cray.com \
--to=paf@cray.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.