From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 5 12:01:27 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E6633C8; Fri, 5 Dec 2014 12:01:27 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0098.outbound.protection.outlook.com [157.56.110.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E30DE99; Fri, 5 Dec 2014 12:01:26 +0000 (UTC) Received: from DM2PR04MB477.namprd04.prod.outlook.com (10.141.105.13) by DM2PR04MB478.namprd04.prod.outlook.com (10.141.105.16) with Microsoft SMTP Server (TLS) id 15.1.26.15; Fri, 5 Dec 2014 12:01:16 +0000 Received: from DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.29]) by DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.29]) with mapi id 15.01.0026.003; Fri, 5 Dec 2014 12:01:15 +0000 From: Mike Gelfand To: "freebsd-hackers@freebsd.org" Subject: Re: [BUG] Getting path to program binary sometimes fails Thread-Topic: [BUG] Getting path to program binary sometimes fails Thread-Index: AQHP/y1OF6HbydE23kCBwyNP5wFRKZxeymWAgAEZIgCACdtQgIAXSR6A Date: Fri, 5 Dec 2014 12:01:15 +0000 Message-ID: References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> <20141113170758.GY17068@kib.kiev.ua> <201411201125.30087.jhb@freebsd.org> In-Reply-To: <201411201125.30087.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [128.140.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB478; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB478; x-forefront-prvs: 04163EF38A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(51704005)(24454002)(377454003)(199003)(2351001)(105586002)(107046002)(77156002)(99286002)(83716003)(106116001)(20776003)(102836002)(62966003)(106356001)(68736005)(64706001)(66066001)(93886004)(36756003)(46102003)(99396003)(2656002)(101416001)(120916001)(21056001)(4396001)(50986999)(76176999)(54356999)(40100003)(122556002)(19580395003)(92566001)(31966008)(86362001)(97736003)(19580405001)(87936001)(82746002)(33656002)(110136001)(104396002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR04MB478; H:DM2PR04MB477.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <7791A140A95D7C42921E4887978CDBEA@namprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: logicnow.com X-Mailman-Approved-At: Fri, 05 Dec 2014 12:52:03 +0000 Cc: Konstantin Belousov , "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 12:01:27 -0000 John, Sorry for late reply. On Nov 20, 2014, at 7:25 PM, John Baldwin wrote: >=20 >> Since you=92re saying that current behavior is not a defect, maybe=20 >> documentation is wrong (incomplete, misleading) then? I will readily acc= ept=20 >> the =93not a defect=94 explanation, but only if one wouldn=92t have to a= sk you every=20 >> time this oddity is met. If this is the expected error condition, what s= hould=20 >> I do to get the path reliably? Should I retry (and how many times)? You= =92re=20 >> saying cache is being purged; does it mean that when I ask for path then= cache=20 >> is populated again? Does it guarantee then that I=92ll be able to get th= e path=20 >> on next call? Could you guarantee that I=92ll be able to get the path at= all if=20 >> I fail two or more times? Should I rely on ENOENT specifically when retr= ying? >=20 > Is this over NFS? NFS is more aggressive than local filesystems in purgi= ng > name cache entries because there are inherent races in NFS with certain=20 > fileservers (ones that don't use sub-second timestamps), so by default en= tries=20 > always expire after about a minute. You can change that via the 'nametim= eo'=20 > mount option (takes a count in seconds). No, not NFS but ZFS. Could that be an issue? The FreeBSD 8 machine I mentio= ned before has UFS. Also, as you can see from the video I recorded (and from the code I provide= d), path resolution succeeds and fails within fractions of a second after p= rocess startup. Regards, Mike=