From: Benny Halevy <bhalevy@panasas.com>
To: NFS list <linux-nfs@vger.kernel.org>
Subject: [RFC 0/4] move layout get/return synchronization to rpc prepare
Date: Tue, 14 Sep 2010 12:52:42 +0200 [thread overview]
Message-ID: <4C8F53FA.5060308@panasas.com> (raw)
The following patchset introduces a per-inode rpc wait queue
to be used to synchronize layout gets and returns during
their respective rpc prepare phase.
Essentially, layout gets wait on layout segments marked as invalid,
currently meaning there is a layout return in progress.
It should be ok to send the layout get anyway but waiting avoids
the race rather than having to possibly resolve it on the done path.
In the future layout gets could insert the layout segment they ask
for as "invalid" so that parallel layout gets would wait too.
However, since the server may return a different segment than
requested (bigger or smaller), there's no guarantee that the
parallel layoutget will overlap the one in progress.
Layout returns wait on layout segments while they are being used
(e.g. for I/O operations).
[PATCH 1/4] SQUASHME: pnfs-post-submit: remove take_ref and only_valid params from pnfs_has_layout
[PATCH 2/4] pnfs: allow nfs4_proc_layoutget to sleep on invalid lsegs
[PATCH 3/4] pnfs: allow nfs4_proc_layoutreturn to sleep on barrier
[PATCH 4/4] SQUASHME: pnfs: get rid of lo_waitq
next reply other threads:[~2010-09-14 10:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-14 10:52 Benny Halevy [this message]
2010-09-14 10:53 ` [PATCH 1/4] SQUASHME: pnfs-post-submit: remove take_ref and only_valid params from pnfs_has_layout Benny Halevy
2010-09-14 10:53 ` [PATCH 2/4] pnfs: allow nfs4_proc_layoutget to sleep on invalid lsegs Benny Halevy
2010-09-14 12:00 ` Fred Isaman
2010-09-14 12:40 ` Benny Halevy
2010-09-14 12:47 ` Fred Isaman
2010-09-14 13:13 ` Benny Halevy
2010-09-14 10:53 ` [PATCH 3/4] pnfs: allow nfs4_proc_layoutreturn to sleep on barrier Benny Halevy
2010-09-14 10:53 ` [PATCH 4/4] SQUASHME: pnfs: get rid of lo_waitq Benny Halevy
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=4C8F53FA.5060308@panasas.com \
--to=bhalevy@panasas.com \
--cc=linux-nfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).