Date: Mon, 28 Jul 1997 10:43:18 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: davidn@labs.usn.blaze.net.au, msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG Subject: Re: utmp/wtmp interface Message-ID: <199707281743.KAA01338@phaeton.artisoft.com> In-Reply-To: <199707280816.RAA05659@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 28, 97 05:46:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707281743.KAA01338>