Date: Sat, 15 Feb 2003 09:18:09 +0000 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Gordon Tetlow <gordont@gnf.org>, Garance A Drosihn <drosih@rpi.edu>, arch@FreeBSD.ORG Subject: Re: syslog.conf syntax change (multiple program/host specifications) Message-ID: <200302150918.09807.wes@softweyr.com> In-Reply-To: <3E4DB9F1.83B7746D@mindspring.com> References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302141725.00421.wes@softweyr.com> <3E4DB9F1.83B7746D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302150918.09807.wes>