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.
> >
> > 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.
>
> Now that's a wrong assumption. A file is a row of bytes. The only
> thing I can assume is that if I write a byte at a certain position, I
> will get the same byte back when reading the file. Furthermoe, the
> file size (not the disk space used!) is the largest position written.
> If I assume anything more, I'm assuming too much.
>
> For an application, having sparse files is completely transparant. The
> application doesn't even know the difference. How the OS stores the
> file is up to the OS.
>
> Again, assuming a copy of a file takes up as much space as the
> original is wrong.
>
> > On the other hand, I agree with you that handling sparse files
> > efficiently is rather neat in an OS.
Okay - I understand your logic, and yes, I do know about sparse files
and how they are typically handled. And yes, you are right that
there are very good reasons for handling sparse files this way.
And yes, application are right to make use of this feature where
applicable.
However, in this case, it's a simple log file, and what the application
did, while very much technically correct, clearly violated the principle
of least astonishment, for no real reason I can see. Sure, trying to
make efficient use of every single byte may not be very efficient - but
just zeroing out the first five GB of the file is more than a little
hackish, and not really necessary.
Joachim
