Date: Fri, 5 Dec 2014 12:01:15 +0000 From: Mike Gelfand <Mike.Gelfand@LogicNow.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, "hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: [BUG] Getting path to program binary sometimes fails Message-ID: <BC392D92-5DD4-4012-90D4-17C4BC1566CE@logicnow.com> In-Reply-To: <201411201125.30087.jhb@freebsd.org> References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> <20141113170758.GY17068@kib.kiev.ua> <B655709E-0D6F-4DE1-A746-9A20B897BEA8@logicnow.com> <201411201125.30087.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John, Sorry for late reply. On Nov 20, 2014, at 7:25 PM, John Baldwin <jhb@freebsd.org> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC392D92-5DD4-4012-90D4-17C4BC1566CE>