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-head mailing list