Date: Sun, 16 Feb 2003 07:45:04 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Wes Peters <wes@softweyr.com> Cc: arch@FreeBSD.ORG Subject: Re: syslog.conf syntax change (multiple program/host specifications) Message-ID: <20030215204503.GA56102@cirb503493.alcatel.com.au> In-Reply-To: <200302150918.09807.wes@softweyr.com> References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302141725.00421.wes@softweyr.com> <3E4DB9F1.83B7746D@mindspring.com> <200302150918.09807.wes@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 15, 2003 at 09:18:09AM +0000, Wes Peters wrote: >On Saturday 15 February 2003 03:54, Terry Lambert wrote: >> What might be more useful, in this particular case, since you want >> only the last 120K is a means of truncating deleting cytes off the >> front of a file. You'd probably want to allow any value, but in >> terms of avoiding rewriting, in practice, you probably want to >> constrain it to an even multiple of the FS block size. > >Well, I certainly don't want any of that. I want to be able to lop the >first 11 bytes of a 2^30 byte file and have exactly that data in the file >the next time I access it. This is somewhat different to what Terry was proposing but I agree it would be immensely useful. I also fairly regularly run into the situation where I want an indefinitely sized FIFO and simulating such a beast is quite a nuisance without this. Definitely, for this sort of thing, you don't want to be constrained by the underlying filesystem blocksize. (One obvious situation is where you have a producer that generates important data and if the consumer stops or falls behind you can't afford to either block the producer or lose the data). >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. Peter 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?20030215204503.GA56102>