From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 19 Dec 2013 18:59:00 +0100 From: Steffen "Daode" Nurpmeso To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20131219175900.4iIYysllOqvWL89Lj2hXAiQF@dietcurd.local> References: <3e1e9e6fbfa856a01013a2f51b8d244f@coraid.com> <34270f8ddb3fc06e71d4db496a891dd4@brasstown.quanstro.net> <71f34c7f2a7fac1912f332bbdb14e2ac@brasstown.quanstro.net> In-Reply-To: User-Agent: s-nail v14.5-1-geec08e3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_01387475940=-EU1lvG2Y2z/DtxY5u3X8pOgUBvVGOO=_" Subject: Re: [9fans] mk time-check/slice issue Topicbox-Message-UUID: a203d7b0-ead8-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --=_01387475940=-EU1lvG2Y2z/DtxY5u3X8pOgUBvVGOO=_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Blake McBride wrote: |On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom wrote: | |>> I was thinking about the problem and actually, at least in all |>> circumstances I can think of, changing that one operation from <= to < |>> would fix the problem. If the times are on the same second, I would |> |> i thought this idea might come up. i think the reason not to do this |> is a very fundamental principle: correctness. never give up on |> correctness. |> |I for one favor practical usefulness over theoretical correctness. An I think on FAT filesystems even giving up correctness won't help you with it's two second resolution. --steffen --=_01387475940=-EU1lvG2Y2z/DtxY5u3X8pOgUBvVGOO=_ Content-Type: message/rfc822 Content-Disposition: inline Content-Description: Original message content Delivered-To: sdaoden@gmail.com Received: by 10.42.112.10 with SMTP id w10csp33849icp; Thu, 19 Dec 2013 08:02:20 -0800 (PST) X-Received: by 10.43.0.202 with SMTP id nn10mr1680964icb.54.1387468940349; Thu, 19 Dec 2013 08:02:20 -0800 (PST) Return-Path: <9fans-bounces@9fans.net> Received: from mail.9fans.net (mail.9fans.net. [67.207.142.3]) by mx.google.com with ESMTPS id k10si4863652igx.65.2013.12.19.08.01.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 19 Dec 2013 08:02:20 -0800 (PST) Received-SPF: pass (google.com: domain of 9fans-bounces@9fans.net designates 67.207.142.3 as permitted sender) client-ip=67.207.142.3; Authentication-Results: mx.google.com; spf=pass (google.com: domain of 9fans-bounces@9fans.net designates 67.207.142.3 as permitted sender) smtp.mail=9fans-bounces@9fans.net; dkim=fail header.i=@gmail.com Received: from localhost ([127.0.0.1] helo=[67.207.142.3]) by mail.9fans.net with esmtp (Exim 4.71) (envelope-from <9fans-bounces@9fans.net>) id 1VtgFz-0002xX-R6; Thu, 19 Dec 2013 16:15:27 +0000 Received: from gw17.lax01.mailroute.net ([199.89.0.117] helo=mail.mailroute.net) by mail.9fans.net with esmtp (Exim 4.71) (envelope-from ) id 1VtgFy-0002xQ-3P for 9fans@9fans.net; Thu, 19 Dec 2013 16:15:26 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by gw17.lax01.mailroute.net (Postfix) with ESMTP id 3dld721LMmzYjFf for <9fans@9fans.net>; Thu, 19 Dec 2013 15:58:54 +0000 (GMT) X-Virus-Scanned: by MailRoute X-X-Spam-Flag: NO X-X-Spam-Score: -0.567 X-X-Spam-Level: X-X-Spam-Status: No, score=-0.567 tagged_above=-9999 tests=[DKIM_VALID=-0.01, DKIM_VERIFIED=-0.01, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MR_RCVD_TLS=-0.1, RCVD_IN_MSPIKE_H2=-0.718, SPF_PASS=-0.001, T_FREEMAIL_FORGED_FROMDOMAIN=0.01, T_HEADER_FROM_DIFFERENT_DOMAINS=0.01] autolearn=disabled Authentication-Results: gw17.lax01.mailroute.net (mroute_mailscanner); dkim=pass (2048-bit key) header.d=gmail.com Received: from gw17.lax01.mailroute.net ([127.0.0.1]) by localhost (gw17.lax01.mailroute.net [127.0.0.1]) (mroute_mailscanner, port 10024) with LMTP id bXVECBFBUuXe for <9fans@9fans.net>; Thu, 19 Dec 2013 15:58:49 +0000 (GMT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gw17.lax01.mailroute.net (Postfix) with ESMTPS id 3dld6x26HvzYjG8 for <9fans@9fans.net>; Thu, 19 Dec 2013 15:58:49 +0000 (GMT) Received: by mail-ie0-f178.google.com with SMTP id lx4so1538464iec.37 for <9fans@9fans.net>; Thu, 19 Dec 2013 07:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=bL7rDJJ4yNDICRMys+77iLsf53ASYfF9pe94QgDx82I=; b=sCwdVjTKkfUg9lLWb6UZQXxYNLKbZndJc92iVOBX2SWmiDmVlFv2ZgiopuUOPSwtaP o5PQeFBf5xL2cRXolKQ+2EF2FOpDq4Onef13PKfkepi1w8fftWu+xo2iutaHAnqBgg8S MCF3Sad8p+NfTUpLzZRRMr9HEG6TqBvqJG6svpTEFUO/5u+s+E98s3iFu5vxebuTI0T1 96qGxXo5RK0j76v0Bm/OUoVdv6muwgTGflCoL0/n22Ts6+r1Kf8xM4E3ziUlICCB1+l6 SV22pEohi4ZUE0vUVTASMZlhVJIg0E8/sYWDbmIeNjF9ZSOfckQEnfHS09lLPbJexRTZ yeFw== MIME-Version: 1.0 X-Received: by 10.42.224.194 with SMTP id ip2mr461913icb.91.1387468728756; Thu, 19 Dec 2013 07:58:48 -0800 (PST) Received: by 10.64.146.37 with HTTP; Thu, 19 Dec 2013 07:58:48 -0800 (PST) In-Reply-To: <71f34c7f2a7fac1912f332bbdb14e2ac@brasstown.quanstro.net> References: <3e1e9e6fbfa856a01013a2f51b8d244f@coraid.com> <34270f8ddb3fc06e71d4db496a891dd4@brasstown.quanstro.net> <71f34c7f2a7fac1912f332bbdb14e2ac@brasstown.quanstro.net> Date: Thu, 19 Dec 2013 09:58:48 -0600 X-Google-Sender-Auth: WkF_zgV9TLMqdEzl0v9bnJAt7nQ Message-ID: From: Blake McBride To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1133251eb72eff04ede53c1f Subject: Re: [9fans] mk time-check/slice issue X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces@9fans.net Status: RO --001a1133251eb72eff04ede53c1f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom wrote: > > I was thinking about the problem and actually, at least in all > > circumstances I can think of, changing that one operation from <= to < > > would fix the problem. If the times are on the same second, I would > never > > have had time to change it. This would fix the problem. Perhaps this > > functionality can be controlled by an environment variable like NPROC. > > i thought this idea might come up. i think the reason not to do this > is a very fundamental principle: correctness. never give up on > correctness. > > I for one favor practical usefulness over theoretical correctness. An environment variable option would trivially satisfy both groups. It could operate as-is so nothing pre-existing would be affected. Blake --001a1133251eb72eff04ede53c1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 19, 2013 at 8:55 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> I was thinking about = the problem and actually, at least in all
> circumstances I can think of, changing that one operation= from <=3D to <
> would fix the problem. =A0If the times are on the same se= cond, I would never
> have had time to change it. =A0This would fix the problem= . =A0Perhaps this
> functionality can be controlled by an environment variabl= e like NPROC.

i thought this idea might come up. =A0i thi= nk the reason not to do this
is a very fundamental principle: correctness. =A0never give up on correctness.


I for one favor practical usefulness=A0over theoreti= cal correctness. =A0An environment variable option would trivially satisfy= =A0both groups. It could operate as-is so nothing pre-existing would be aff= ected.

Blake
=A0
--001a1133251eb72eff04ede53c1f-- --=_01387475940=-EU1lvG2Y2z/DtxY5u3X8pOgUBvVGOO=_--