The strangeness called `sbin'

[Garrett Cooper]

On Thu, Nov 10, 2011 at 10:43 AM, Peter Wemm <peter at wemm.org> wrote:
> On Thu, Nov 10, 2011 at 10:12 AM, Garrett Cooper <yanegomi at gmail.com> wrote:
>> On Thu, Nov 10, 2011 at 9:47 AM, Ed Schouten <ed at 80386.nl> wrote:
>>> * Peter Wemm <peter at wemm.org>, 20111110 18:33:
>>>> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse
>>>> than having no /sbin at all, from a perspective of rootvnode lock
>>>> lifetime.  If you can figure out how to get people to remove /sbin and
>>>> /usr/sbin from their paths after the symlink changes then it becomes a
>>>> moot point.  But heck, I still have /usr/X11R6 in mine... :(
>>>
>>> On the other hand, if people used to have /sbin in their path and *do*
>>> remove it properly after the upgrade, they should in theory see a
>>> performance improvement, right?
>>
>>    Doesn't the negative directory cache (namei, etc) mitigate this?
>> Thanks!
>
> Yes, the negative cache entries in the name cache should help.
>
> You know, we have very good tools to characterize the effects on
> this.. see ministat(1).
>
> I'd be interested to see if the effects are worth worrying about on things like:
>
> repeated shell startup (think: system(3)), or sh -c "somecommand"
> buildworld time
> runtime of non-trivial shell scripts, eg: configure, perl Configure etc
> runtime of other some perl scripts that have a bunch of system() or
> `cmd` all over the damn place.
>
> .. all with and without optimal $PATHs and bad $PATHs.
>
> The one that I can't think of a good way to characterize would be
> systemic effects on rootvnode locking from hitting a /sbin->/bin
> symlink.  That's harder to measure because it affects other users of
> the system than the item under test.
>
> Even things like sh -c "command" is hard to measure because it'll hit
> the name cache with 100% success and won't test the cache miss cases.

gnn / Professor McKusick's book -- the Design and Implementation of
FreeBSD -- suggests that this is an optimal method, but the benchmarks
were run some time ago and hardware has changed. I think that
rerunning the benchmarks on i386 vs amd64 vs {arm,mips,etc} would
definitely be a good idea.

Thanks!
-Garrett