Date: Thu, 9 Mar 2017 03:15:32 +0300 From: Rozhuk Ivan <rozhuk.im@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: open(): O_EVTONLY and O_NOATIME Message-ID: <20170309031532.0079ab35@rimwks> In-Reply-To: <20170308235016.GT30979@kib.kiev.ua> References: <20170309022554.18875d07@rimwks> <20170308235016.GT30979@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 9 Mar 2017 01:50:16 +0200 Konstantin Belousov <kostikbel@gmail.com> wrote: > > Can some one add O_EVTONLY and O_NOATIME to open()? > Sure, somebody can, but it might be that nobody will. > O_EVTONLY require knowledge about kqueue internals, I have not it. > > 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 ? If some one already open and lock dir/file you can not open it. > > 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. > May be we should do like other OS that already have O_NOATIME? > 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. ???? If file system cant be mount with NOATIME - then it already ready to support O_NOATIME.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170309031532.0079ab35>