[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Aug 11 02:35:22 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491

--- Comment #8 from Conrad Meyer <cem at freebsd.org> ---
(In reply to Garance A Drosehn from comment #5)
(In reply to Garance A Drosehn from comment #7)
> but why would using nscd be so much slower than doing a totally non-cached look
> up of the user and group names each time?  Doesn't that seem a little odd?

You're totally right, that does seem suspect.  Maybe our ncsd isn't the same
one as on Linux, or is an older version, or has some other deficiency?  I admit
total lack of familiarity with any version or use of ncsd. :-)

> And the local-to-stat caching:  won't that only help if many commands are
> 'stat'-ed in a single command, as opposed to doing many stat-commands with one
> file per command?

Correct.  That's the use case described in Thomas' description, although I
don't know if it represents any realworld workflow or if it's just an arbitrary
pessimistic microbenchmark.  If the latter, I don't think it's worth bringing
in the stat(1) patch.  (Even if it is a real-world use, the non-general
optimization is questionable and we need to investigate why ncsd doesn't solve
the problem first.)

> Does 'ls' do local caching?  If there is a big benefit in doing local-caching
> in 'stat', should we also do it with 'ls'?  I know I do a lot more 'ls -l's
> than I do 'stat'-commands of any kind.

Another great question, and the answer is yes — through a 3rd method.  ls uses
user_from_uid(), group_from_gid(), which caches any implementation of
getpwuid() / getgrgid().  Fortunately, libc's default implementation of these
routines already uses _nsdispatch(), so it is not limited to local /etc/passwd.

So tl;dr: Instead of this patch, stat(1) should just use user_from_uid(3) /
group_from_gid(3) (pwcache(3) API).

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list