Date: Tue, 18 Feb 2003 05:11:15 +0000 From: Wes Peters <wes@softweyr.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: arch@FreeBSD.ORG Subject: Re: syslog.conf syntax change (multiple program/host specifications) Message-ID: <200302180511.15013.wes@softweyr.com> In-Reply-To: <20030215204503.GA56102@cirb503493.alcatel.com.au> References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302150918.09807.wes@softweyr.com> <20030215204503.GA56102@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 15 February 2003 20:45, Peter Jeremy wrote:
> On Sat, Feb 15, 2003 at 09:18:09AM +0000, Wes Peters wrote:
>
> >Right, only I don't have anywhere near the filesystem-foo to implement
> > such a change. I suppose it could be done relatively straightforward
> > by allowing the original leading disk blocks to be marked unused and
> > making an offset to the beginning of the file field in the inode,
> > that counts bytes to skip into the first truly allocated block.
>
> This doesn't sound too difficult - we can already free blocks from the
> end of a file so it shouldn't be too difficult to free blocks from the
> beginning of a file. Adding a start-of-file offset to I/O operations
> is almost a mechanical operation. The only hard part would be finding
> space in the inode for another off_t.
>
> The downside of this is that there would be an upper limit on the total
> number of bytes that can be written to the file (ie when you run out of
> triple-indirect blocks). You could avoid this by dropping unused
> blocks at the front and shifting the remaining blocks forwards in the
> inode. (Probably as groups of blocks to avoid the need to move block
> pointers within indirect blocks). This would also reduce the size of
> the offset from off_t to enough to represent an indirect block of
> bytes.
Yeah, if you "re-normalize" the file every time you truncate at the
beginning, you don't need a full off_t, just an offset up to blocksize.
Not much of a difference, and I have no idea how the re-normalization
would affect performance; it's certainly not zero cost. The alternative
is to use an off_t and only re-normalize when necessary, which would be
the simpler solution.
--
Where am I, and what am I doing in this handbasket?
Wes Peters wes@softweyr.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302180511.15013.wes>