From owner-freebsd-hackers Tue Aug 29 18:40:25 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id SAA02825 for hackers-outgoing; Tue, 29 Aug 1995 18:40:25 -0700 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id SAA02819 for ; Tue, 29 Aug 1995 18:40:22 -0700 Received: (from bugs@localhost) by ns1.win.net (8.6.11/8.6.9) id VAA07404 for hackers@freebsd.org; Tue, 29 Aug 1995 21:45:40 -0400 From: Mark Hittinger Message-Id: <199508300145.VAA07404@ns1.win.net> Subject: re: re: pwd_mkdb is intense To: hackers@freebsd.org Date: Tue, 29 Aug 1995 21:45:39 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1798 Sender: hackers-owner@freebsd.org Precedence: bulk Our password file is around 11552 lines now (and growing daily). Actually I dislike the structure of the db password file. On a more vanilla level my experience with mixing keys and data records in the same file has nearly always been bad. I'd rather have the binary pw records in one flat file and three additional files that have the keys/pointers to the binary pw records. This would insulate the data from the db package. It looks to me like we have each "pw" record in the system 8 times? I have about 8.5 megabytes devoted to this structure. 1. /etc/passwd record 2. /etc/master.passwd record 3. /etc/pwd.db pw record keyed by username 4. /etc/pwd.db pw record keyed by count 5. /etc/pwd.db pw record keyed by uid 6. /etc/spwd.db shadow pw record keyed by username 7. /etc/spwd.db shadow pw record keyed by count 8. /etc/spwd.db shadow pw record keyed by uid I realize that pwd_mkdb is doing a ton of stuff to preserve compatibility and support shadowing/locking. I am assuming here that there is not some soft parameter that I can pump up in pwd_mkdb to make it a screamer :-) I see a cache size parameter in a hash structure. I will try to increase that tommorrow and see what happens. Maybe there is something down in the gut level db stuff that I can pump up also. In an environment where accounts are constantly being added or updated the current system is sub-optimal. For a new account I'd rather append records to passwd, master.passwd, a hypothetical flat binary pw record file, a hypothetical flat binary pw shadow file, and then add keys to the three seperate key files. For the updates I just would have to get the record, lock it, and alter the flat record. There is no need to recreate the keys. Regards, Mark Hittinger bugs@win.net