Date: Tue, 29 Jul 1997 08:15:13 +1000 From: David Nugent <davidn@labs.usn.blaze.net.au> To: Terry Lambert <terry@lambert.org> Cc: msmith@atrad.adelaide.edu.au (Michael Smith), freebsd-hackers@FreeBSD.ORG Subject: Re: utmp/wtmp interface Message-ID: <199707282215.IAA24833@labs.usn.blaze.net.au> In-Reply-To: Your message of "Mon, 28 Jul 1997 10:43:18 MST." <199707281743.KAA01338@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. I definitely disagree. > Without an index, a large utmp/wtmp would be unbearably slow. No, it isn't. Whether accessed forwards or reverse order, wtmp is invariably accessed *sequentially*. An index is entirely unnecessary, and nor is it slow. I have working code here that shows it to be pretty much comparable with fixed length records, even though a variable length (newline delimited) record is used *and* parsed. The cost is a little more code, but certainly not performance to any significant degree. > The way it works now, multiplying the record number by the size of the > struct keeps it happy. The way it would work would be to read in blocks of data until EOF, and scanned from either end of the file. The internal parser scans for newlines and keeps track of where it is at in the internal buffer. Using an index for sequentially accessed data is just unnecessary overhead. utmp is of course different. init primarily manages this and needs to *update* records in it, which are accessed randomly. This really does need to be fixed length format. I'm currently reworking the interface(s) based on suggestions by a number of people, which will solve the problem of using static data completely. Actually it is based on a paradigm I've used quite often, and I have no idea why it didn't occur to me to use it here as well. :-/ I'll announce again when I'm done (I'd say a few days, but the way things are right now, it might be a few weeks :-(). And Terry, just for you, I'll include the proposed new version of last that uses the getwt*() api and the wtmp (current format) -> wtmp (text) converter which will demonstrate my point with regards to performance; you only need to recompile/install the new libutil to change the format you want to test with (which is really the point of this exercise). FWIW, if anything truely wants to access wtmp randomly, it isn't so hard to write some code to index whatever you want into a .db file (or memory, for that matter). The idea here isn't so much the format itself, but that file access be hidden behind files be behind a standard API. Once that is done, then you can add bells and whistles like the .db index(es) or mmap()ing, or whatever you like by modifying one library function. I'm actually not really intended to (yet) rework the file formats, although obviously I had a strong leaning towards a varlen text format for wtmp and nothing else fancy to solve imaginary problems. Regards, David -- David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707282215.IAA24833>