[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120619165520.GA11015@milliways>
Date: Tue, 19 Jun 2012 17:55:20 +0100
From: Ken Moffat <zarniwhoop@...world.com>
To: "Myklebust, Trond" <Trond.Myklebust@...app.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: nfs3 problem with -rc{2,3} : blame
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists