From owner-freebsd-hackers Mon Jul 28 10:45:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA20463 for hackers-outgoing; Mon, 28 Jul 1997 10:45:06 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA20442 for ; Mon, 28 Jul 1997 10:44:59 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA01338; Mon, 28 Jul 1997 10:43:18 -0700 From: Terry Lambert Message-Id: <199707281743.KAA01338@phaeton.artisoft.com> Subject: Re: utmp/wtmp interface To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 28 Jul 1997 10:43:18 -0700 (MST) Cc: davidn@labs.usn.blaze.net.au, msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199707280816.RAA05659@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 28, 97 05:46:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Actually, I would have suggested a textual format, but I thought that > > > the screams would be audible from here. If you think it's a goer, you > > > have my absolute support. > > > > Given the space savings, I can't see any reason for it NOT to be > > text. All but a couple of the fields are text anyway. :) I recently > > played with a 13mb wtmp which reduced down to 4.8mb when converted > > to variable-length text (this was a 8-character username system too), > > which should give you some idea of the potential savings. > > Eep. Pretty convincing. > > > This will make it harder for things like last(1) to page back > > through the file from the end, but life is sometimes tough. Besides, > > last(1) will use the API, which will handle this transparently in any > > case, including the buffering. > > Yup. Sounds good. I suggest that you provide either a fixed lenth record format, or a fixed length header containing an index. Without an index, a large utmp/wtmp would be unbearably slow. The way it works now, multiplying the record number by the size of the struct keeps it happy. As an alternative, I think it would be nice to have an index prefixed block compressed mmap(). The RAM image would be uncompressed and accessed normally as an mmap'ed file, but the file acting as the backing store would be compressed. This would also be usedful for standard file compression, if you had a bit in the inode to mark the thing; otherwise, and mmap() flag is a good first cut. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.