Date: Thu, 9 Mar 2017 15:11:36 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: "O'Connor, Daniel" <darius@dons.net.au> Cc: Rozhuk Ivan <rozhuk.im@gmail.com>, freebsd-hackers@freebsd.org Subject: Re: open(): O_EVTONLY and O_NOATIME Message-ID: <20170309131136.GY30979@kib.kiev.ua> In-Reply-To: <C49C6526-942A-44E0-9D21-BAA95C5DCDA2@dons.net.au> References: <20170309022554.18875d07@rimwks> <20170308235016.GT30979@kib.kiev.ua> <20170309031532.0079ab35@rimwks> <C49C6526-942A-44E0-9D21-BAA95C5DCDA2@dons.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 09, 2017 at 02:50:36PM +1030, O'Connor, Daniel wrote: > > > On 9 Mar 2017, at 10:45, Rozhuk Ivan <rozhuk.im@gmail.com> wrote: > > > >> consider the most often cause for atime update, read(2): VFS > >> translates the syscall through all its layers into VOP_READ() call > >> for fs-specific action, and the signature of the call is > >> VOP_READ(struct vnode *, struct uio *, int ioflag, struct > >> ucred *); As you see, there file is already down-casted to vnode, and > >> of course we do not want the vnode to loose atime updates just > >> because one file is opened which asked for no atime updates. As > >> result, upper VFS layers must pass a flag to VOP_READ(). > >> > >> You are welcome to finish the analysis and to prototype the solution. > > > > ???? > > If file system cant be mount with NOATIME - then it already ready to support O_NOATIME. > > Konstantin means that due to the way the file system driver gets requests there is no information about how they were opened in the first place. > > This means that there is no way it could look at all the FDs which have this file open and see they are all noatime and then disable atime just for that one. Well, I never claimed that the 'look at all the FDs' is needed. I stated that some plumbing to pass O_NOATIME flag from file down to VOPs is needed if this feature is implemented. > > You are right in that if an FS can be mounted noatime it should be able to work but unfortunately there is no plumbing between the open of the file and the file system that supports that. I fail to understand this statement. How somebody's ability to edit /etc/fstab is related to potential unintended or malicious lack of metadata update due to the mis-use of the flags ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170309131136.GY30979>