[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FA345DA4F4AE44899BD2B03EEEC2FA909236BB5@SACEXCMBX04-PRD.hq.netapp.com>
Date: Mon, 15 Oct 2012 04:27:35 +0000
From: "Myklebust, Trond" <Trond.Myklebust@...app.com>
To: Chen Gang <gang.chen@...anux.com>
CC: Jeff Layton <jlayton@...hat.com>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Bug fix] nfs-client: fix nfs_inode_attrs_need_update for async
read_done comes during truncating to smaller size
On Mon, 2012-10-15 at 10:12 +0800, Chen Gang wrote:
> Hello Trond Myklebust, Jeff Layton:
>
> 1) Root Cause:
> A) begin truncate to smaller, after async read finish starting.
> B) async read done come, after truncate operation change inode size.
> C) in nfs_inode_attrs_need_update, nfs_size_need_update return true.
> i) the bigger size is the original old size of client itself.
> ii) the smaller size is the current true size.
> iii) nfs_inode_attrs_need_update not consider this situation.
>
> 2) Fix nfs_size_need_update:
> A) delete it:
> i) it is for performance, not necessary (not for correctness).
> ii) if it was necessary, it should use "!=" instead of '>'.
> iii) it is the simplest way to fix this bug (maybe not best way).
> B) consider this situation in it:
> i) it is the best way.
> ii) it is a little complex (need think of)
> iii) sorry for I do not know how to fix it (at least now).
> C) not touch it:
> i) correct another place (such as nfs_update_inode)
> ii) it is a bad idea (at least, I think it is)
> iii) we need keep the source code as clearer as possible.
>
> 3) Test Result:
> A) it is one client and one server separately, under 3.6-rc5 x86_32.
> B) use one process (fsx-linux) test (only one user mode thread).
> C) only use read, truncate, llseek, fstat operation for one file.
>
> Before delete nfs_size_need_update, it causes issue.
> After delete nfs_size_need_update, it is ok.
nfs_size_need_update is not about performance. It is a heuristic that is
entirely about ensuring correctness when faced with the fact that most
Linux filesystems are utterly incapable of reporting with modifications
that occur within < 1 second intervals because their mtime/ctime is
limited to 1 second resolutions.
Now, what are the conditions of your test setup? The above bug report is
meaningless unless it includes a description of what is being exported
by the server (including a proper listing of the contents
of /etc/exports and /proc/mounts). It should also include a description
of the NFS client mount options (see /proc/mounts on the client).
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@...app.com
www.netapp.com
Powered by blists - more mailing lists