From owner-svn-src-all@FreeBSD.ORG Sun Mar 22 16:25:14 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A447206; Sun, 22 Mar 2015 16:25:14 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5807276; Sun, 22 Mar 2015 16:25:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2MGP7po019258 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 22 Mar 2015 18:25:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2MGP7po019258 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2MGP7Ik019256; Sun, 22 Mar 2015 18:25:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Mar 2015 18:25:07 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: svn commit: r280308 - head/sys/fs/devfs Message-ID: <20150322162507.GD2379@kib.kiev.ua> References: <201503210114.t2L1ECcB075556@svn.freebsd.org> <20150321200221.K1846@besplex.bde.org> <20150322133709.GA39238@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150322133709.GA39238@stack.nl> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI , Bruce Evans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 16:25:14 -0000 On Sun, Mar 22, 2015 at 02:37:09PM +0100, Jilles Tjoelker wrote: > On Sat, Mar 21, 2015 at 08:49:00PM +1100, Bruce Evans wrote: > > On Sat, 21 Mar 2015, Xin LI wrote: > > > > Log: > > > Disable timestamping on devfs read/write operations by default. > > > > Currently we update timestamps unconditionally when doing read or > > > write operations. This may slow things down on hardware where > > > reading timestamps is expensive (e.g. HPET, because of the default > > > vfs.timestamp_precision setting is nanosecond now) with limited > > > benefit. > > > > A new sysctl variable, vfs.devfs.dotimes is added, which can be > > > set to non-zero value when the old behavior is desirable. > > > I don't like this. It defaults to non-POSIX-conformant behaviour... > > > The slowness is mostly from no delayed update of times in devfs. > > Switching vfs.timestamp_precision to a hardware timecounter would > > have been even more expensive for regular files if file systems > > didn't have delayed updates. The assumption that vfs_timestamp() > > doesn't use a slow timecounter was so often satisfied that no one > > missed devfs also not supporting mounting with -noatime. > > > Delayed updates are even easier to implement for devfs than for disk > > file systems the times never need to be written to disk. A slow update > > is still wasteful for atimes, but not as bad as for disk file systems > > since it doesn't trigger a slower sync to disk. > > Yes, I think implementing delayed updates is the right solution to this > problem. This way, only stat and last close will need to read the clock. > No configuration option will be needed. > > A subtle difference with most other file systems is that devfs nodes > often stay open for very long, so the timestamps will usually come from > stat() calls, which may be much later than the actual read or write. > Still that is better than not updating timestamps at all. > > > > ... > > > Modified: head/sys/fs/devfs/devfs_vnops.c > > > ============================================================================== > > > --- head/sys/fs/devfs/devfs_vnops.c Sat Mar 21 00:21:30 2015 (r280307) > > > +++ head/sys/fs/devfs/devfs_vnops.c Sat Mar 21 01:14:11 2015 (r280308) > > > ... > > > @@ -1700,7 +1708,8 @@ devfs_write_f(struct file *fp, struct ui > > > resid = uio->uio_resid; > > > > > > error = dsw->d_write(dev, uio, ioflag); > > > - if (uio->uio_resid != resid || (error == 0 && resid != 0)) { > > > + if (devfs_dotimes && > > > + (uio->uio_resid != resid || (error == 0 && resid != 0))) { > > > vfs_timestamp(&dev->si_ctime); > > > dev->si_mtime = dev->si_ctime; > > > } > > > An old bug is evident in the diff. Writing shouldn't change the ctime. > > That is not a bug. POSIX unambiguously requires write() to update both > mtime and ctime. Does POSIX ever say anything about special files ? Devfs already has non-POSIX behaviour, e.g. write on one mount is reflected as mtime/ctime update on all mounts. On reboot, the time stamps are re-created, i.e. changes are not persistent. I think the deviations may be summarrized as 'devfs mtime is useless for the usual mtime purposes'. From this PoV, I have no objections to the patch. Doing extra work with delayed updates of times, which might be somewhat non-trivial, is a feature with non-obvious gain.