From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>,
Bernd Schubert <bs@q-leap.de>,
Randy Dunlap <randy.dunlap@oracle.com>,
linux-kernel@vger.kernel.org,
"J. Bruce Fields" <bfields@fieldses.org>,
brian@clusterfs.com
Subject: Re: patch: improve generic_file_buffered_write() (2nd try 1/2)
Date: Sat, 08 Sep 2007 11:43:03 +0200 [thread overview]
Message-ID: <874pi5cx20.fsf@informatik.uni-tuebingen.de> (raw)
In-Reply-To: <200709081731.51263.nickpiggin@yahoo.com.au> (Nick Piggin's message of "Sat, 8 Sep 2007 17:31:50 +1000")
Nick Piggin <nickpiggin@yahoo.com.au> writes:
> Lustre should probably have to be ported over to write_begin/write_end in
> order to use it too. With the patches in -mm, if a filesystem is still using
> prepare_write/commit_write, the vm reverts to a safe path which avoids
> the deadlock (and allows multi-seg io copies), but copies the data twice.
Not quite relevant for the performance problem. The situation is like
this:
lustre servers <-lustre network protocol-> lustre client <-NFS-> desktop
The NFSd problem is on the lustre client that only plays gateway. That
is not to say that the lustre servers or desktop loose performance due
to fragmenting writes too but it isn't that noticeable there.
> OTOH, this is very likely to go upstream, so your filesystem will need to be
> ported over sooner or later anyway.
Lustre copies the ext3 source from the kernel, patches in some extra
features and renames them during build. So one the one hand it always
breaks whenever someone meddles with the ext3 code. On the other hand
improvement for ext3 get picked up by lustre semi automatically.
In this case lustre would get the begin_write() function from ext3 and
use it.
MfG
Goswin
next prev parent reply other threads:[~2007-09-08 9:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-05 13:45 patch: improve generic_file_buffered_write() Bernd Schubert
2007-09-05 15:35 ` Randy Dunlap
2007-09-05 17:41 ` patch: improve generic_file_buffered_write() (2nd try 1/2) Bernd Schubert
2007-09-05 17:49 ` patch: improve generic_file_buffered_write() (2nd try 2/2) Bernd Schubert
2007-09-08 4:15 ` patch: improve generic_file_buffered_write() (2nd try 1/2) Nick Piggin
2007-09-07 20:01 ` Goswin von Brederlow
2007-09-08 6:28 ` Nick Piggin
2007-09-07 21:12 ` Goswin von Brederlow
2007-09-08 7:25 ` Nick Piggin
2007-09-08 7:31 ` Nick Piggin
2007-09-08 9:43 ` Goswin von Brederlow [this message]
2007-09-07 20:12 ` Nick Piggin
2007-09-07 21:00 ` Goswin von Brederlow
2007-09-08 7:14 ` Nick Piggin
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=874pi5cx20.fsf@informatik.uni-tuebingen.de \
--to=brederlo@informatik.uni-tuebingen.de \
--cc=bfields@fieldses.org \
--cc=brian@clusterfs.com \
--cc=bs@q-leap.de \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=randy.dunlap@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®