Date: Thu, 9 Mar 2017 02:33:08 +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: <20170309003308.GU30979@kib.kiev.ua> In-Reply-To: <20170309031532.0079ab35@rimwks> References: <20170309022554.18875d07@rimwks> <20170308235016.GT30979@kib.kiev.ua> <20170309031532.0079ab35@rimwks>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 09, 2017 at 03:15:32AM +0300, Rozhuk Ivan wrote: > 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. I have to repeat the question. Which lock could be applied by user which prevents other opens ? > > > > > 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? What other OSes do ? > > > > 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. I do not understand this statement.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170309003308.GU30979>