From owner-freebsd-arch Sat Feb 15 1:24:40 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC78937B401 for ; Sat, 15 Feb 2003 01:24:37 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27F5443F3F for ; Sat, 15 Feb 2003 01:24:37 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-75-151-22.san.rr.com [66.75.151.22]) by smtp-relay.omnis.com (Postfix) with ESMTP id 2F45543491; Sat, 15 Feb 2003 01:18:10 -0800 (PST) From: Wes Peters Organization: Softweyr To: Terry Lambert Subject: Re: syslog.conf syntax change (multiple program/host specifications) Date: Sat, 15 Feb 2003 09:18:09 +0000 User-Agent: KMail/1.5 Cc: Gordon Tetlow , Garance A Drosihn , arch@FreeBSD.ORG References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302141725.00421.wes@softweyr.com> <3E4DB9F1.83B7746D@mindspring.com> In-Reply-To: <3E4DB9F1.83B7746D@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302150918.09807.wes@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday 15 February 2003 03:54, Terry Lambert wrote: > Wes Peters wrote: > > > > The real problem we're looking at is that ftruncate(2) doesn't take a > > third argument describing which end you want to truncate at. Such a > > facility would end this argument quickly, syslog could simply truncate > > the first (filesize - desired log size) bytes of the file and be done > > with it. > > This would solve the immediate "file too large" problem, but it > wouldn't maintain the history properly; you'd end up with 0, 40K, > a 60M-40K gap in the history, and then realy old 40K x 3. Probably > the right interface is "donate this block range to file X starting > at block offset Q, zeroing the corresponding blocks in this file, > sparsely, if you can". > > It's a twisty little problem, probably not worth a general API, > unless you can know the block granularity on the underlying FS, > at which sparse blocks existed, and constrain it to use that. I disagree, it's a problem I run into frequently and a general API would solve the entire class of problems once and for all. > BTW: the SVR4 fcntl() that's the moral equivalent of ftruncate > supports exactly the syntax you want (e.g. free up space at the > start of the file for 60M-120K, replacing with sparseness -- it > can put sparse blocks in the middle of files). Yes, I recall that fondly. It seems weird for BSD to have less functionality, especially in the filesystem. > 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. > > Short of getting ufs2 to provide frag blocks at both ends of the file, > > this is about as good as it gets. I'll get my -current system up this > > weekend and have a patch to review in a few days. > > If you do this, just implement the SVR4 fcntl(); it basically takes > an fcntl() lock structure, e.g.: > > > fcntl( fd, F_FREESP, struct flock *) > > l_whence SEEK_SET/SEEK_CUR/SEEK_END > l_start > l_len > > FWIW, the manual allows restriction to the end of the file, but in > practice, that's not what happens on SVR4 systems. 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. It's easy to see why ufs doesn't have the functionality, but that doesn't keep me from wanting it... -- 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