On Tue, Jan 17, 2006 at 02:15:57PM +0100, Otto Moerbeek wrote:
> On Tue, 17 Jan 2006, Daniel Ouellet wrote:
>
> > OK,
> >
> > Here is the source of the problem. The cache file generated by
> > webazolver is the source of the problem. Based on the information of
> > the software webalizer, as this:
> >
> > "Cached DNS addresses have a TTL (time to live) of 3 days. This may
> > be changed at compile time by editing the dns_resolv.h header file
> > and changing the value for DNS_CACHE_TTL."
> >
> > The cache file is process each night, and the records older then 3
> > days are remove, but somehow that file become a sparse file in the
> > process and when copy else where show it's real size. In my case
> > that file was using a bit over 4 millions blocks more then it should
> > have and give me the 4GB+ difference in mirroring the content.
> >
> > So, as far as I can see it, this process of expiring the records
> > from the cache file that is always reuse doesn't shrink the file
> > really, but somehow just mark the records inside the file as bad, or
> > something like that.
> >
> > So, nothing to do with OpenBSD at all but I would think there is a
> > bug in the portion of webalizer however base on what I see from it's
> > usage.
> >
> > Now the source of the problem was found and many thanks to all that
> > stick with me along the way.
>
> You are wrong in thinking sparse files are a problem. Having sparse
> files quite a nifty feature, I would say.
Are we talking about webazolver or OpenBSD?
I'd argue that relying on the OS handling sparse files this way instead
of handling your own log data in an efficient way *is* a problem, as
evidenced by Daniels post. After all, it's reasonable to copy data to,
say, a different drive and expect it to take about as much space as the
original.
On the other hand, I agree with you that handling sparse files
efficiently is rather neat in an OS.
Joachim
