From owner-svn-src-head@FreeBSD.ORG Sun Mar 29 20:04:17 2015 Return-Path: Delivered-To: svn-src-head@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 D94A84E9; Sun, 29 Mar 2015 20:04:17 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (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 639F89B; Sun, 29 Mar 2015 20:04:17 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2TK41q4091900; Sun, 29 Mar 2015 12:04:05 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503292004.t2TK41q4091900@gw.catspoiler.org> Date: Sun, 29 Mar 2015 13:04:01 -0700 (PDT) From: Don Lewis Subject: Re: svn commit: r280308 - head/sys/fs/devfs To: jilles@stack.nl In-Reply-To: <20150329175137.GD95224@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org, delphij@FreeBSD.org, brde@optusnet.com.au, kostikbel@gmail.com X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 20:04:18 -0000 On 29 Mar, Jilles Tjoelker wrote: > On Sun, Mar 22, 2015 at 11:25:07AM -0700, Don Lewis wrote: >> It's not totally worthless. I think the mtime on tty devices is used to >> calculate the idle time that is printed by the w command. We just don't >> need nanosecond accuracy for that. > > Hmm. The idle time on tty devices breaking is a clear POLA violation, > but I'm not sure what's the best way to fix it. By the way, w uses atime > and who -u uses mtime. > > Some options are: > > * Bypass vfs_timestamp() and hard-code second accuracy in devfs; > futimens() will still set timestamps to the nanosecond, even with > UTIME_NOW. A timestamp update after UTIME_NOW setting may set back the > timestamp to an older value. I'm ok with this. I'd even be ok with forbidding futimens(). > * Make vfs.timestamp_precision filesystem-specific. Since this does not > affect futimens() with explicit timestamps, it will not cause strange > situations with cp -p. I think this might be unnecessarily complex. > * Restrict file times on devfs to seconds. > > * Somehow add a special case for TTY devices so they will always keep > timestamps. Also a possibility, though I don't see the need for better than one second accuracy. > * Somehow add a special case for "performance-critical" devices so they > will not keep timestamps. Maybe, but if we can make timestamps cheap enough, it might not matter. > * Change the default for vfs.timestamp_precision to 1, which still > provides non-zero nanoseconds (so much of the same bugs) but is not so > slow. The file server people won't like this though. And it doesn't solve the problem if the system has mixed usage. > My proposal for delayed updates as in UFS clearly does not work for TTY > idle times, so there is no point in that. Yeah. The reason for delayed updates is that it reduces the writeback traffic to the underlying filesystem. That's not a concert for devfs even if it would work. I think it would just add extra complexity.