All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ken Moffat <zarniwhoop@ntlworld.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: nfs3 problem with -rc{2,3} : blame
Date: Tue, 19 Jun 2012 17:55:20 +0100	[thread overview]
Message-ID: <20120619165520.GA11015@milliways> (raw)
In-Reply-To: <1340123001.3754.11.camel@lade.trondhjem.org>

On Tue, Jun 19, 2012 at 04:23:23PM +0000, Myklebust, Trond wrote:
> On Tue, 2012-06-19 at 12:20 -0400, Trond Myklebust wrote:
> > 
> > However you are saying that the problem is there when you compile a
> > kernel with this commit as the head, and it goes away when you compile a
> > kernel with commit 3e9e0ca3f19e911ce13c2e6c9858fcb41a37496c as the head?
> > 
 Provided I apply 4f97615d as well, so that it compiles, yes.

> > I'm confused as to how a bug in that patch could depend on
> > CONFIG_NFS_V4, but I'll see what I can find.

 Thanks
> 
> By the way, I thought your test-case was doing firefox downloads. Do
> those really use O_DIRECT?
> 
 I originally saw the problem doing that, but it was on the second
download.  Or perhaps third or fourth - I tend not to remember
successful downloads when I've got a lot of packages to check for new
versions.  Using my backup script seemed a more reliable way to
trigger a problem (but, only if there is something substantial to
back up, such as a new vmlinuz).

 Thinking about this, it is almost certain that between the first
download and the one that failed (several hours later) my backup
script did run, from fcron, so I now think the rsync problem is what
leads to issues when other programs later try to update the same nfs
directory.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce

  reply	other threads:[~2012-06-19 16:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-17 20:07 nfs3 problem with -rc{2,3} Ken Moffat
2012-06-18  1:11 ` Ken Moffat
2012-06-18 13:42 ` Myklebust, Trond
2012-06-18 13:45   ` Myklebust, Trond
2012-06-18 14:18     ` Ken Moffat
2012-06-18 14:53       ` Myklebust, Trond
2012-06-18 16:00         ` Ken Moffat
2012-06-18 20:05           ` Ken Moffat
2012-06-18 20:11             ` Myklebust, Trond
2012-06-18 23:38               ` Ken Moffat
2012-06-18 23:44                 ` Ken Moffat
2012-06-18 21:53             ` Ken Moffat
2012-06-18 22:03               ` Myklebust, Trond
2012-06-18 22:10                 ` Ken Moffat
2012-06-19  1:06                   ` nfs3 problem with -rc{2,3} : blame Ken Moffat
2012-06-19 16:20                     ` Myklebust, Trond
2012-06-19 16:23                       ` Myklebust, Trond
2012-06-19 16:55                         ` Ken Moffat [this message]
2012-06-19 17:46                           ` Myklebust, Trond
2012-06-19 19:35                             ` Ken Moffat
2012-06-19 22:44                               ` Myklebust, Trond
2012-06-19 23:31                                 ` Ken Moffat

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=20120619165520.GA11015@milliways \
    --to=zarniwhoop@ntlworld.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-kernel@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 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.