From owner-freebsd-hackers@freebsd.org Wed Mar 8 23:50:22 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE0C2D0240F for ; Wed, 8 Mar 2017 23:50:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7710E19E7 for ; Wed, 8 Mar 2017 23:50:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v28NoHll030956 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 01:50:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v28NoHll030956 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v28NoG68030952; Thu, 9 Mar 2017 01:50:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Mar 2017 01:50:16 +0200 From: Konstantin Belousov To: Rozhuk Ivan Cc: freebsd-hackers@freebsd.org Subject: Re: open(): O_EVTONLY and O_NOATIME Message-ID: <20170308235016.GT30979@kib.kiev.ua> References: <20170309022554.18875d07@rimwks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170309022554.18875d07@rimwks> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 23:50:23 -0000 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.