From: David Chinner <dgc@sgi.com>
To: Zach Brown <zach.brown@oracle.com>
Cc: Badari Pulavarty <pbadari@gmail.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
David Chinner <dgc@sgi.com>
Subject: Re: [RFC] fs io with struct page instead of iovecs
Date: Thu, 8 Nov 2007 07:44:57 +1100 [thread overview]
Message-ID: <20071107204457.GL995458@sgi.com> (raw)
In-Reply-To: <4731EF8D.5090701@oracle.com>
On Wed, Nov 07, 2007 at 09:02:05AM -0800, Zach Brown wrote:
> Badari Pulavarty wrote:
> > On Tue, 2007-11-06 at 17:43 -0800, Zach Brown wrote:
> >> At the FS meeting at LCE there was some talk of doing O_DIRECT writes from the
> >> kernel with pages instead of with iovecs. T
> >
> > Why ? Whats the use case ?
>
> Well, I think there's a few:
>
> There are existing callers which hold a kmap() across ->write, which
> isn't great. ecryptfs() does this. That's mentioned in the patch
> series. Arguably loopback should be using this instead of copying some
> fs paths and trying to call aop methods directly.
>
> I seem to remember Christoph and David having stories of knfsd folks in
> SGI wanting to do O_DIRECT writes from knfsd? (If not, *I* kind of want
> to, after rolling some patches to align net rx descriptors :)).
The main reason is to remove the serialised writer problem when multiple
clients are writing to the one file. With XFS and direct I/O, we can have
multiple concurrent writers to the one file and have it scale rather than be
limited to what a single cpu holding the i_mutex can do....
> Lustre shows us that there is a point at which you can't saturate your
> network and storage if your cpu is copying all the data.
Buy more CPUs ;)
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
prev parent reply other threads:[~2007-11-07 20:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-07 1:43 [RFC] fs io with struct page instead of iovecs Zach Brown
2007-11-07 1:43 ` [PATCH 1/4] struct rwmem: an abstraction of the memory argument to read/write Zach Brown
2007-11-07 1:43 ` [PATCH 2/4] dio: use rwmem to work with r/w memory arguments Zach Brown
2007-11-07 1:43 ` [PATCH 3/4] add rwmem type backed by pages Zach Brown
2007-11-07 1:43 ` [PATCH 4/4] add dio interface for page/offset/len tuples Zach Brown
2007-11-07 16:50 ` [RFC] fs io with struct page instead of iovecs Badari Pulavarty
2007-11-07 17:02 ` Zach Brown
2007-11-07 20:44 ` David Chinner [this message]
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=20071107204457.GL995458@sgi.com \
--to=dgc@sgi.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=pbadari@gmail.com \
--cc=zach.brown@oracle.com \
/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.