From owner-freebsd-arch@FreeBSD.ORG Mon Apr 16 07:00:52 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C313916A40E for ; Mon, 16 Apr 2007 07:00:52 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 3F0B713C4AD for ; Mon, 16 Apr 2007 07:00:51 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l3G6nnQx015227; Mon, 16 Apr 2007 09:49:50 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3G6nnER001038; Mon, 16 Apr 2007 09:49:49 +0300 Received: from [192.168.136.22] (ppp121-97.adsl.forthnet.gr [193.92.228.97]) by MX-IN-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3G6nfHb024207; Mon, 16 Apr 2007 09:49:41 +0300 Authentication-Results: MX-IN-02.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <46231C64.9010707@aueb.gr> Date: Mon, 16 Apr 2007 09:49:08 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Robert Watson References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> In-Reply-To: <20070415105157.J84174@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 07:00:52 -0000 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