Message 224779 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	larry
Recipients	Claudiu.Popa, francismb, koobs, larry, pitrou, puppet
Date	2014-08-04.22:34:46
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1407191686.66.0.852871145468.issue19838@psf.upfronthosting.co.za>
In-reply-to

Content
And to further confirm, on my Linux machine with a ZFS partition: * stat() returns nanosecond resolution. * I have utimensat(), which supports nanosecond resolution. * The test code correctly sets "utime.now = 1", so it correctly calls utimensat() with a time pointer of NULL. It still fails, but here the race is much closer: before: 1407191476502407010 after: 1407191476502090829 before <= after False If I run the test on a different filesystem (e.g. on /tmp which is ext4) the problem doesn't occur. My guess: it's ZFS's fault in both cases, it's not using the highest-precision timer available.

And to further confirm, on my Linux machine with a ZFS partition:

* stat() returns nanosecond resolution.
* I have utimensat(), which supports nanosecond resolution.
* The test code correctly sets "utime.now = 1", so it correctly calls utimensat() with a time pointer of NULL.

It still fails, but here the race is much closer:

    before: 1407191476502407010
     after: 1407191476502090829
    before <= after False

If I run the test on a different filesystem (e.g. on /tmp which is ext4) the problem doesn't occur.

My guess: it's ZFS's fault in both cases, it's not using the highest-precision timer available.

History
Date	User	Action	Args
2014-08-04 22:34:46	larry	set	recipients: + larry, pitrou, Claudiu.Popa, francismb, koobs, puppet
2014-08-04 22:34:46	larry	set	messageid: <1407191686.66.0.852871145468.issue19838@psf.upfronthosting.co.za>
2014-08-04 22:34:46	larry	link	issue19838 messages
2014-08-04 22:34:46	larry	create