open(): O_EVTONLY and O_NOATIME

[Rozhuk Ivan]

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.


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