From: Martin Brandenburg <martin@omnibond.com>
To: hubcap@omnibond.com, linux-fsdevel@vger.kernel.org
Cc: Martin Brandenburg <martin@omnibond.com>
Subject: [PATCH 00/13] [RFC] orangefs page cache
Date: Mon, 22 May 2017 05:58:48 -0400 [thread overview]
Message-ID: <1495447141-12216-1-git-send-email-martin@omnibond.com> (raw)
OrangeFS has not used the page cache in the past. This is a work in
progress patch to support it. It does not yet make any attempt to do
writeback in a reasonable timeframe considering that OrangeFS is a
distributed filesystem.
What's done:
Inodes are written through write_back: getattrs and setattrs are not
necessarily sent to the server.
Pages are read from and written to the cache on readpage and writepage
and direct_IO works. Some consolidation of code handling the different
read cases allow this diff to decrease code size.
Future work:
The old getattr cache will need to be changed significantly. It
specifies a timeout which should be used by the new code. Though the
old getattr cache gave quite a performance boost, it's cached data would
be destroyed on drop_inode.
Really the only way to do a getattr is during orangefs_iget. Pages are
only read into the cache once. Using this code with multiple clients
will not work at all. Ultimately we will need to do writeback much
faster than at present and know when to fill requests from the cache and
when to require a server request.
The good news is that operating under such a delay found several race
conditions in our code which had not been detected because we always did
a server request in the past.
Does this look like a reasonable start?
Martin Brandenburg (13):
orangefs: move orangefs_address_operations to file.c
orangefs: remove orangefs_readpages
orangefs: make orangefs_inode_read static
orangefs: only set a_ops for regular files
orangefs: BUG_ON if i_mode invalid
orangefs: remove mapping_nrpages macro
orangefs: set up and use backing_dev_info
orangefs: initialize new inode size to zero
orangefs: inodes linger in cache
orangefs: implement direct_IO for the read case
orangefs: lock inode during fsync
orangefs: call generic_file_read_iter
orangefs: implement write through the page cache
fs/orangefs/file.c | 232 ++++++++++++++++++++++++--------------
fs/orangefs/inode.c | 252 +++++-------------------------------------
fs/orangefs/namei.c | 13 ++-
fs/orangefs/orangefs-kernel.h | 8 +-
fs/orangefs/orangefs-utils.c | 7 ++
fs/orangefs/super.c | 54 +++++++--
fs/orangefs/symlink.c | 1 -
7 files changed, 242 insertions(+), 325 deletions(-)
--
2.1.4
next reply other threads:[~2017-05-22 21:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 9:58 Martin Brandenburg [this message]
2017-05-22 9:58 ` [PATCH 01/13] orangefs: move orangefs_address_operations to file.c Martin Brandenburg
2017-05-22 9:58 ` [PATCH 02/13] orangefs: remove orangefs_readpages Martin Brandenburg
2017-05-22 9:58 ` [PATCH 03/13] orangefs: make orangefs_inode_read static Martin Brandenburg
2017-05-22 9:58 ` [PATCH 04/13] orangefs: only set a_ops for regular files Martin Brandenburg
2017-05-22 9:58 ` [PATCH 05/13] orangefs: BUG_ON if i_mode invalid Martin Brandenburg
2017-05-22 9:58 ` [PATCH 06/13] orangefs: remove mapping_nrpages macro Martin Brandenburg
2017-05-22 9:58 ` [PATCH 07/13] orangefs: set up and use backing_dev_info Martin Brandenburg
2017-05-22 9:58 ` [PATCH 08/13] orangefs: initialize new inode size to zero Martin Brandenburg
2017-05-22 9:58 ` [PATCH 09/13] orangefs: inodes linger in cache Martin Brandenburg
2017-05-22 9:58 ` [PATCH 10/13] orangefs: implement direct_IO for the read case Martin Brandenburg
2017-05-22 9:58 ` [PATCH 11/13] orangefs: lock inode during fsync Martin Brandenburg
2017-05-25 15:58 ` Jeff Layton
2017-05-26 16:21 ` martin
2017-05-26 16:58 ` Jeff Layton
2017-05-22 9:59 ` [PATCH 12/13] orangefs: call generic_file_read_iter Martin Brandenburg
2017-05-22 9:59 ` [PATCH 13/13] orangefs: implement write through the page cache Martin Brandenburg
2017-05-25 16:09 ` Jeff Layton
2017-05-26 18:09 ` martin
2017-05-26 18:48 ` Jeff Layton
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=1495447141-12216-1-git-send-email-martin@omnibond.com \
--to=martin@omnibond.com \
--cc=hubcap@omnibond.com \
--cc=linux-fsdevel@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).