From owner-freebsd-hackers@freebsd.org Thu Mar 9 00:33:18 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 2E4E3D01D58 for ; Thu, 9 Mar 2017 00:33:18 +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 CB1E21111 for ; Thu, 9 Mar 2017 00:33:17 +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 v290X8wl040821 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 02:33:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v290X8wl040821 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v290X8Ln040820; Thu, 9 Mar 2017 02:33:08 +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 02:33:08 +0200 From: Konstantin Belousov To: Rozhuk Ivan Cc: freebsd-hackers@freebsd.org Subject: Re: open(): O_EVTONLY and O_NOATIME Message-ID: <20170309003308.GU30979@kib.kiev.ua> References: <20170309022554.18875d07@rimwks> <20170308235016.GT30979@kib.kiev.ua> <20170309031532.0079ab35@rimwks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170309031532.0079ab35@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: Thu, 09 Mar 2017 00:33:18 -0000 On Thu, Mar 09, 2017 at 03:15:32AM +0300, Rozhuk Ivan wrote: > On Thu, 9 Mar 2017 01:50:16 +0200 > Konstantin Belousov 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.