Date: Thu, 25 Sep 2003 09:03:08 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Rong-en Fan <rafan@infor.org> Cc: fs@freebsd.org Subject: Re: NFS incorrectly update atime Message-ID: <20030925084707.T5088@gamplex.bde.org> In-Reply-To: <20030924172237.GA95815@muse.csie.ntu.edu.tw> References: <20030924172237.GA95815@muse.csie.ntu.edu.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 25 Sep 2003, Rong-en Fan wrote: > I'm using FreeBSD 4.8-RELEASE for both NFS server and client, > however when i append file from client, it updates both > atime and mtime, where atime shouldn't be updated. > > $ touch testfile > $ stat testfile > Access: Thu Sep 25 01:17:43 2003 > Modify: Thu Sep 25 01:17:43 2003 > Change: Thu Sep 25 01:17:43 2003 > $ echo foobar >> testfile > $ stat testfile > Access: Thu Sep 25 01:17:43 2003 > Modify: Thu Sep 25 01:19:15 2003 > Change: Thu Sep 25 01:19:15 2003 > $ echo foobar >> testfile > $ stat testfile > Access: Thu Sep 25 01:19:31 2003 > Modify: Thu Sep 25 01:19:31 2003 > Change: Thu Sep 25 01:19:31 2003 This still happens in -current. I think it is normal nfs brokenness... > it only occur when file is not empty, also i've noticed that Writes to 8K boundaries also don't update the atime. I tried "dd if=/dev/zero of=8k count=1 >>foobar". 8K is my server's filesystem block size. I'm not sure if this magic number is for the server or nfs-related. I think the client just does a read as part of a read-modify-write. It works with blocks, so it must do a read before write in all cases where the write is not on a block boundary, and at least FreeBSD ffs servers have no way to avoid updating the atime on read short of a global mount -noatime. Some of the reads, including ones from small test files in your example, may be from a client cache, so the atime update might be avoided accidentally, but a read will always be necessay if the cache is cold. > http://www.freebsd.org/cgi/query-pr.cgi?pr=44580 > is the same problem. BTW, i also test it on 5.1-RELEASE, > and got the same result. This was misclassified in the "i386" category where it is hard to see (unfortunately there is an i386 mailing list which seems to have no activity except for blackholing i386 PRs). It has nothing to do with i386's, so I moved it to the "kern" category. gnats seems to be broken -- didn't prompt for a reason. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030925084707.T5088>