Date: Fri, 10 Aug 2018 04:22:25 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching Message-ID: <bug-230491-227-9VaT2bv7rP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230491-227@https.bugs.freebsd.org/bugzilla/> References: <bug-230491-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 Conrad Meyer <cem@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cem@freebsd.org --- Comment #1 from Conrad Meyer <cem@freebsd.org> --- Patch looks functionally ok to me (works because stat is a single-threaded program); has some style issues. It's unclear to me if we want to add caching to every individual tool accessing these databases, or if the caching should just happen in libc. One other concern that the thought of caching in libc raises is: how do we handle cache invalidation? Obviously we don't care if a user/group change races a running but ultimately bounded program like stat(1) across many files, but we probably do care if a daemon never sees renamed or numbered ids. Btw, it seems such caching is already implemented in libc via the NS_CACHING option. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230491-227-9VaT2bv7rP>