Re: df -h stats for same file systems display different result son AMD64 then on i386 (Source solved)

2006-01-17 Thread Daniel Ouellet
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

Re: df -h stats for same file systems display different result son AMD64 then on i386 (Source solved)

2006-01-17 Thread Otto Moerbeek
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

Re: df -h stats for same file systems display different result son AMD64 then on i386 (Source solved)

2006-01-17 Thread Joachim Schipper
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:

Re: df -h stats for same file systems display different result son AMD64 then on i386 (Source solved)

2006-01-17 Thread Otto Moerbeek
On Tue, 17 Jan 2006, Joachim Schipper wrote: On Tue, Jan 17, 2006 at 02:15:57PM +0100, Otto Moerbeek wrote: 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

Re: df -h stats for same file systems display different result son AMD64 then on i386 (Source solved)

2006-01-17 Thread Daniel Ouellet
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,

Re: df -h stats for same file systems display different result son AMD64 then on i386 (Source solved)

2006-01-17 Thread Joachim Schipper
On Tue, Jan 17, 2006 at 05:49:24PM +0100, Otto Moerbeek wrote: On Tue, 17 Jan 2006, Joachim Schipper wrote: On Tue, Jan 17, 2006 at 02:15:57PM +0100, Otto Moerbeek wrote: You are wrong in thinking sparse files are a problem. Having sparse files quite a nifty feature, I would say.

Re: df -h stats for same file systems display different result son AMD64 then on i386 (Source solved)

2006-01-17 Thread Matthias Kilian
On Tue, Jan 17, 2006 at 02:36:44PM -0500, Daniel Ouellet wrote: [...] But having a file that is let say 1MB of valid data that grow very quickly to 4 and 6GB quickly and takes time to rsync between servers were in one instance fill the fill system and create other problem. (: I wouldn't

Re: df -h stats for same file systems display different result son AMD64 then on i386 (Source solved)

2006-01-17 Thread Daniel Ouellet
Hi all, First let me start with my apology to some of you for having waisted your time! As much as this was/is interesting and puzzling to me and that I am trying obviously to get my hands around this issue and usage of sparse files, the big picture of it, is obviously something missing in