Date: Mon, 30 Mar 2015 14:47:29 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jilles Tjoelker <jilles@stack.nl> Cc: src-committers@freebsd.org, Don Lewis <truckman@freebsd.org>, svn-src-head@freebsd.org, delphij@freebsd.org, brde@optusnet.com.au, kostikbel@gmail.com, svn-src-all@freebsd.org Subject: Re: svn commit: r280308 - head/sys/fs/devfs Message-ID: <20150330140932.D1560@besplex.bde.org> In-Reply-To: <20150329175137.GD95224@stack.nl> References: <20150322162507.GD2379@kib.kiev.ua> <201503221825.t2MIP7jv096531@gw.catspoiler.org> <20150329175137.GD95224@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 29 Mar 2015, 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. POSIX specifies that the idle time is the time since _any_ activity occured on the terminal; the method of determining this time is unspecified. So both w and who -u are arguably wrong. They could look at both the mtime and the atime, and possibly even the ctime and the btime, and more (a device i/o time, which is not available). But looking at the atime alone is reasonable. It gives a time related to the user typing on the terminal. This depends on the user's application reading the output and something (hopefully not just w) updating the atime. mtime updates are related to the application writing the terminal, and this can happen without the user being present. > 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. Probably enough, but I worry about the times going backwards. calcru() has complicated code to give monotonic times, but still spams to console and gives broken times when the times would have gone backwards without the correction. > * 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 could use this, but it is too complicated. I sometimes run tests which need to change the precision. I want this only on the filesystem running the tests, but get it globally. So I try to change it only transiently, but sometimes forget to change back. > * Restrict file times on devfs to seconds. This is reasonable. It gives the same bug as the seconds resolution setting (that timestamps are more than 1 second in the past despite sychronization that would prevent this if the system conformed to POSIX) because time_second lags clocks that read the hardware. > * Somehow add a special case for TTY devices so they will always keep > timestamps. > > * Somehow add a special case for "performance-critical" devices so they > will not keep timestamps. > > * 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. Monotonic and unique is probably enough. > My proposal for delayed updates as in UFS clearly does not work for TTY > idle times, so there is no point in that. It gives what ufs always did when device files were on it instead of on devfs. The immediated devfs updates don't give correct atimes either. The atime is only set when something reads the tty, but the user's activity may be much earlier than that (when the application doing the reading is delayed, perhaps significantly in actual use by the application being stopped or buffering). But the delays are usually short. Users would complain if input is not acted on by more than the tty driver echo within 20 milliseconds. Even more so if the echo/action is done by the application. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150330140932.D1560>