Date: Sun, 22 Mar 2015 18:25:07 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI <delphij@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r280308 - head/sys/fs/devfs Message-ID: <20150322162507.GD2379@kib.kiev.ua> In-Reply-To: <20150322133709.GA39238@stack.nl> References: <201503210114.t2L1ECcB075556@svn.freebsd.org> <20150321200221.K1846@besplex.bde.org> <20150322133709.GA39238@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150322162507.GD2379>