Pádraig Brady wrote:
> Just a quick follow up to this now archived bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472590
>
> The last message there mentioned selinux query overhead.
> On my system with selinux disabled, there is currently
> a significant overhead in doing the selinux lookup per file
> with a standard `ls -l` listing.
> A quick test shows that I can list 100K files in 0.9s
> with the selinux lookup commented out, while it increases
> to 1.3s when the lookup is done.
>
> I'm not sure how selinux works TBH, but it was mentioned
> in the bug that if it's in one file then it's in all.
> If this was always true then the selinux lookup would only
> need to be done for the first file in the listing?
> If not, then perhaps some caching could be added to
> at least indicate quickly that selinux is disabled on
> the current (file) system.
>
> I know speed isn't that important for ls but it would be nice
> to get back the 40% slow down if possible.
Sounds worthwhile.
AFAIK, you can assume that on a given partition (stat.st_dev),
that attribute (SELinux-affected) is the same for every file.
You might want to do something similar to what I did in fts.c
with this change:
http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=97d5b66578be507
There, I associated each device number encountered with a boolean
indicating whether leaf-optimization works on it.
In ls.c, you'd maintain a map to associate st_dev -> bool selinux_enabled.
You'd need slightly less code than in fts.c, since you won't need to
create/use new struct members. A global hash table would be sufficient.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
