open(): O_EVTONLY and O_NOATIME

[Konstantin Belousov]

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 at 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.