From owner-freebsd-hackers Mon Jan 13 13:50:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA08352 for hackers-outgoing; Mon, 13 Jan 1997 13:50:22 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA08335 for ; Mon, 13 Jan 1997 13:50:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA28246; Mon, 13 Jan 1997 14:10:39 -0700 From: Terry Lambert Message-Id: <199701132110.OAA28246@phaeton.artisoft.com> Subject: Re: truss, trace ?? To: stesin@gu.net (Andrew Stesin) Date: Mon, 13 Jan 1997 14:10:39 -0700 (MST) Cc: karpen@ocean.campus.luth.se, hackers@freebsd.org In-Reply-To: from "Andrew Stesin" at Jan 13, 97 08:07:42 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Sun, 12 Jan 1997, Mikael Karpberg wrote: > > > Yeah, the cyclic file type is (stupidly) missing from unix. > > [...] > > > Or? Am I completely off line here? > > No you aren't. I was thinking on it for years... but > not enough hacking skills to do it actually. Cyclic file types imply record orientation. They do this because you want to remove an atomic record each time from the front of the file in order to add your record to the end of the file. For wtmp style logs, the records are not variable length, so you are pretty much OK. For console logs and message logs, however, you are pretty much screwed. One problem is that the underlying storage is block instead of record oriented anyway. On a VMS system, you'd write a new record and modify an index; on a UNIX system, you would need to be able to instert blocks at the end of the block list (which you can do) and to collapse the block list up (which you can't do, currently). In addition, you would need to be able to have the first block of the file be a right-associative (fill-to-end) instead of a standard left associative (fill-from-start-to-n-bytes) frag. The associativity is important to save copies, and since the truncate from front for the cyclic behavior would result in frags which shrink over time instead of frags which grow over time. All of this is possible, it's just not very pretty, and it doesn't fit in very well with the allocation of indirect blocks... you would need to (effectively) push all pointers up through the small number of direct blocks at the front of the file, as you cycled data through. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.