Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Jan 2009 22:30:33 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Tim Kientzle <kientzle@freebsd.org>
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, "'current@FreeBSD.org'" <current@freebsd.org>
Subject:   Re: RFC: Change mtree nsec handling?
Message-ID:  <20090130203033.GB52415@deviant.kiev.zoral.com.ua>
In-Reply-To: <49833352.3010208@freebsd.org>
References:  <30968.1233310214@critter.freebsd.dk> <49833352.3010208@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--mxv5cy4qt+RJ9ypb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 30, 2009 at 09:05:22AM -0800, Tim Kientzle wrote:
> Poul-Henning Kamp wrote:
> >In message <49829D49.10306@freebsd.org>, Tim Kientzle writes:
> >
> >>mtree support and the mtree(8) program, I found
> >>that mtree formats timestamps rather strangely.
> >>
> >>For example, a timestamp of 1233295862.000001
> >>(1233295682 seconds and 1000 nanoseconds)
> >>will be printed like this by mtree:
> >>  time=3D1233295862.1000
> >>Unsurprisingly, the mtree parsing works the same
> >>way in reverse.
> >
> >>@@ -258,6 +259,8 @@
> >>				val =3D ep + 1;
> >>				ip->st_mtimespec.tv_nsec
> >>				    =3D strtoul(val, &ep, 10);
> >>+				for (i =3D ep - val; i < 9; ++i)
> >>+					ip->st_mtimespec.tv_nsec *=3D 10;
> >
> >
> >Why is this bit needed ?
> >
>=20
> This is the part that converts 1233295862.000001 into
> 1000 nanoseconds (instead of 1 nanosecond).
>=20
> Two reasons:
>  1) Documentation.  It's much easier to document
> "decimal seconds" than "period followed nine digits
> representing the number of nanoseconds past the whole
> second."
>  2) Interoperability.  I originally noticed this testing
> other mtree-producing code against our mtree implementation.
> For example, since FreeBSD filesystems never (?) store
Look at the vfs.timestamp_precision sysctl in
sys/kern/vfs_subr.c

> higher resolution than microseconds, there's really
> no reason to write more than 6 digits after the decimal
> point.  It seems a tad naive to assume that everyone
> will always write 9 digits.
>=20
> I can leave this out for a cycle if there's real concern.
> Fractional seconds occur so rarely on FreeBSD systems
> (to my knowledge, the kernel never spontaneously generates
> them so they can only be created by tools like touch that
> explicitly call utimes()) that I didn't think this
> would affect any real applications.
>=20
> But if I'm wrong....  <shrug>
>=20
> Tim
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

--mxv5cy4qt+RJ9ypb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkmDY2kACgkQC3+MBN1Mb4jNRgCg27il8U7YkkoDwrKn++AzkjyB
AVYAni0NYYRkZJIBO4F3o4Sc3jspkd+p
=hpK9
-----END PGP SIGNATURE-----

--mxv5cy4qt+RJ9ypb--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090130203033.GB52415>