svn commit: r280308 - head/sys/fs/devfs
Don Lewis
truckman at FreeBSD.org
Sun Mar 29 20:04:18 UTC 2015
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.
More information about the svn-src-all
mailing list