Date: Tue, 14 Jan 1997 14:37:13 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: terry@lambert.org (Terry Lambert) Cc: stesin@gu.net, karpen@ocean.campus.luth.se, hackers@FreeBSD.org Subject: Re: truss, trace ?? Message-ID: <199701140339.TAA00166@freefall.freebsd.org> In-Reply-To: <199701132110.OAA28246@phaeton.artisoft.com> from "Terry Lambert" at Jan 13, 97 02:10:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Terry Lambert, sie said:
>
> 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.
Forgive me for being simple, but why do you need to do that at all ?
The way I see it, there some things to consider which you may (or may
not) want to `work' with cyclic files:
* offset - when you pass byte n of an n byte cylic file, should lseek tell
you that you're at byte n+1 or 0 ?
Does it make sense to return n+1 if it can't lseek to that
absolute position ? Would lseek() be hacked to goto position
x as x % n ?
* blocks - why do you need to shuffle blocks around ? Why not just just
the offset pointer once you get to the end ? (In effect, the
write is done in 2 parts: first to the end of the file, the
second from the start).
* readers - if a reader is open and at position y and the next write will
go from x to x+n whre x+n > y does the writer block ? (Consider
that all data from y around to x is valid).
I guess you're thinking of what happens when you keep appending to a file
...(open - write - close. I donm't see that non-block sized record
files can exist as cyclic files properly under Unix, eg:
I have a 30,000 byte cyclic file. I write 1 byte to it, making 30,001.
This isn't enough to delete the first block, but you must append it.
(hmmm, would this mean the first block would be a fragment - would it even
work ?)
Anyone for O_CYCLIC ?
Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701140339.TAA00166>