Date: Mon, 16 Apr 2007 09:49:08 +0300 From: Diomidis Spinellis <dds@aueb.gr> To: Robert Watson <rwatson@FreeBSD.org> Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes Message-ID: <46231C64.9010707@aueb.gr> In-Reply-To: <20070415105157.J84174@fledge.watson.org> References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: >>> What do you think of the idea of changing the file format a little to >>> include a short file header at the front, and that the first field of >>> that head is zero-filled u_int32_t, and the second a version number? >>> Right now, the first field of the acct structure is the name of the >>> command, which will always be a non-nul string, so always have a >>> first character non-nul. If we see non-nul data in the file header's >>> first field, we use the old structure layout, and otherwise we check >>> the version number and use the new layout? This would provide >>> backwards compatibility for reading old accounting data, which I >>> would think would generally be desirable, and allow us to explicitly >>> version the file in the future. >> > > The sites I know of that use accounting don't care about CPU use in the > sa(8) sense at all. They care about tracking commands run. While > acct(5) doesn't do this extraordinarily well, it does it well enough to > allow basic command execution logging and analysis. Hence the desire to > be able to continue readding preserved acct(5) data files in the future. I see three options for satisfying this requirement. One is to move the existing acct.h into usr.bin/lastcomm, and add to lastcomm(1) and option to read legacy files. I don't like this approach, because it doesn't include sa(8) in the picture, and, more importantly, it doesn't scale well for future changes. Every time we change the type of a field of acct.h (for example widening ac_gid) we will have to add architecture-specific code in the legacy file reading module. A variation of the above approach would be to create a library for reading legacy accounting data formats. I think this is an overkill, given that the two users are sa(8) and lastcomm(1), and of the two lastcomm appears to be really needed. The approach I favor is to add to lastcomm an option to dump an accounting file in text format, and a second option to read text accounting data from stdin and write it out in the current accounting file format. Users can then either store accounting data in (compressed) text files, or pipe them through a pipeline that will transform the legacy format into the current one. (In the latter case they will need to keep through an upgrade a lastcomm(1) binary compiled to read the legacy format - I can provide the appropriate cvs incantation in UPDATING). This approach also simplifies the writing of test cases. Diomidis - http://www.spinellis.gr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46231C64.9010707>