Date: Sun, 11 Jul 1999 10:05:22 -0500 (CDT) From: Joe Greco <jgreco@ns.sol.net> To: ayan@kiwi.datasys.net (Ayan George) Cc: current@freebsd.org Subject: Re: utmp & last Message-ID: <199907111505.KAA77032@aurora.sol.net> In-Reply-To: <199907100928.FAA79011_kiwi.datasys.net@ns.sol.net> from Ayan George at "Jul 10, 1999 9:28:44 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> Why do we store the utmp/wtmp and last logs in different data
> structures?
>
> What seems strange is that they use the different data types to
> store the same information (the time):
>
> struct lastlog {
> time_t ll_time;
> char ll_line[UT_LINESIZE];
> char ll_host[UT_HOSTSIZE];
> };
>
> struct utmp {
> char ut_line[UT_LINESIZE];
> char ut_name[UT_NAMESIZE];
> char ut_host[UT_HOSTSIZE];
> long ut_time;
> };
>
> Not that there is any _real_ difference between long and time_t,
> but it would imagine we'd want to be as consistant as possable.
>
> Anyhow, IMHO the umtp filestructure should be used to store the
> last log. At the same time, I'm sure there is a reason for
> the way things are. Could someone clue me in?
Good programmers don't waste space.
In particular, since the lastlog format uses the uid as the index into
the file, when the format was designed, the maximum file size would have
been 28 * 65536 ~= 1.8MB. By comparison, your suggestion bloats it up
to 36 * 65536 ~= 2.4MB - to add a completely useless field. Now, that
may not seem like a lot, but there was a time and day when we were
installing on 40MB hard drives and were in complete awe at how much space
we had. I remember my first serious FreeBSD box on a pair of 30MB RLL's.
This, of course, assumes the 8-character name that was in use at the time
this format was devised.
Now that we have 32-bit UID's, and 16-character names, it is a bit more
significant... although it is possible to argue that the lastlog format
itself is broken. Defining one really big uid (oh, let's say 2^32-1)
results in a 114GB-sized file, although it is likely to be sparse. :-)
This is still a problem for sparse-unaware utilities. Your approach
would yield a 180GB-sized file. I'm not sure what advantage this extra
66GB waste (that's 37% waste!) would provide.
Your point about time storage is correct, however, I believe. Using
long instead of time_t is just asking for problems. There's probably
some hysterical raison for it.
... Joe
-------------------------------------------------------------------------------
Joe Greco - Systems Administrator jgreco@ns.sol.net
Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907111505.KAA77032>