The strangeness called `sbin'

Peter Wemm peter at wemm.org
Thu Nov 10 18:43:05 UTC 2011


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.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell


More information about the freebsd-arch mailing list