• Mike Hibler's avatar
    Optimize the case of a "usermod -G" which changes only a few groups. · 9ab75810
    Mike Hibler authored
    The handling of group file changes via the -G option is abysmal.
    It creates a new copy of the installed group file on every group line
    changed, fsync'ing after the new copy is made. On top of that, it implements
    a new group list by first removing the user from all existing groups and then
    reading them to every group in the new list, thereby maximizing the number of
    group lines changed!
    
    On the Emulab mothership where, for example, the "geniuser" user is in
    some 450+ groups, adding them to a new group entailed changing 450+ lines
    twice, resulting in over 900 copies of the 2000 line group file being
    written. This took about 17 minutes.
    
    The change here is modest, just check where the group line needs to be
    changed or not before doing anything. In the case above, adding a single
    group for a user, we only write the group file once. This takes about 0.8
    seconds.
    9ab75810
Name
Last commit
Last update
..
FreeBSD-10.0-pw.patch Loading commit data...
FreeBSD-10.1-mountd.patch Loading commit data...
FreeBSD-10.1-pw.patch Loading commit data...
FreeBSD-10.2-mountd.patch Loading commit data...
FreeBSD-10.2-pw-2.patch Loading commit data...
FreeBSD-10.3-pw-2.patch Loading commit data...
FreeBSD-6.3-src.README Loading commit data...
FreeBSD-6.3-src.patch Loading commit data...
Mysql.pm.patch Loading commit data...
SelfLoader.patch Loading commit data...
boost.patch Loading commit data...
g++.patch Loading commit data...
m2crypto.patch Loading commit data...
m2crypto.patch-0.13 Loading commit data...
m2crypto.patch-0.17 Loading commit data...
mailman.patch Loading commit data...
php4-Makefile.patch Loading commit data...
samba.patch Loading commit data...
wireshark-1.12.4-emulab.patch Loading commit data...