Date: Thu, 9 Mar 2017 01:50:16 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Rozhuk Ivan <rozhuk.im@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: open(): O_EVTONLY and O_NOATIME Message-ID: <20170308235016.GT30979@kib.kiev.ua> In-Reply-To: <20170309022554.18875d07@rimwks> References: <20170309022554.18875d07@rimwks>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 09, 2017 at 02:25:54AM +0300, Rozhuk Ivan wrote: > Hi! > > Can some one add O_EVTONLY and O_NOATIME to open()? Sure, somebody can, but it might be that nobody will. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338 devel/glib20: patch: new kqueue() backend for file monitoring > > Without O_NOATIME open() on file/dir always update attributes -> file browsing via sshfs/internet get very slow. > Without O_EVTONLY kqueue() cant monitor dirs/files than locked, also this cause unmount proublems. What do you mean by 'cannot monitor files that are locked' ? In particular, what user-settable locks (advisory locks ?) prevent kqueue(2) event reporting ? > > > IMHO O_NOATIME - easy to add. Hmm. There is an architectural question about allowing user to override the administrator mounting option. If the system configuration mounted the volume without noatime mount option, then why should we allow user to escape the policy ? In particular, access times might provide some important information WRT undesirable incidents, esp. on sealed machines. We might add a new mount option, which would not disable atime, but allow user to request O_NOATIME behaviour. E.g., it could be specified for the monitored volumes on desktops, if I follow your use case. That said, I see two practical troubles with implementation: 1. The atime update is filesystem-specific, i.e. you must teach each filesystem how to react to the flag. At least, UFS, ZFS, msdosfs and tmpfs must be adapted. 2. If you look at any of the filesystems in the list of the #1, you would note that atime is set in the context which already lost any reference to the file which initiated the operation. For instance, 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170308235016.GT30979>