All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	NFS list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] out of order WRITE requests
Date: Wed, 14 Jan 2009 10:38:47 -0500	[thread overview]
Message-ID: <496E0707.70606@redhat.com> (raw)
In-Reply-To: <1231887217.7036.24.camel@heimdal.trondhjem.org>

Trond Myklebust wrote:
>
> Heh.... I happen to have a _very_ similar patch that is basically
> designed to prevent new pages from being dirtied, and thus allowing
> those cache consistency flushes at close() and stat() to make progress.
> The difference is that I'm locking over nfs_write_mapping() instead of
> nfs_writepages()...
>
> Perhaps we should combine the two patches? If so, we need to convert
> nfs_write_mapping() to only flush once using the WB_SYNC_ALL mode,
> instead of the current 2 pass system...

Heh, indeed!  :-)

The combined patch looks fine to me, although I will have to
look at the changes to nfs_write_begin and nfs_write_mapping
to understand what their ramifications are.

I have another patch to propose which adds some flow control
to allow the NFS client to better control the number of pages
which can be dirtied per file.  I implemented this support in
response to a customer who had a server which required in-
order WRITE requests in order to function correctly.  It
also could not handle too much data being sent to it at a
time, so it functioned better when the client spaced out the
sending of data more smoothly.

It turns out that this framework can be used to solve the
stat() problem quite neatly.

I will construct a patch which applies on top of the combined
patch and post that, if that is okay.

    Thanx...

       ps

      parent reply	other threads:[~2009-01-14 15:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-13 22:31 [PATCH] out of order WRITE requests Peter Staubach
2009-01-13 22:53 ` Trond Myklebust
2009-01-13 23:07   ` Trond Myklebust
2009-01-14 15:38   ` Peter Staubach [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=496E0707.70606@redhat.com \
    --to=staubach@redhat.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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.