Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: holes in files
Message-ID: <8432:Dec1622:40:0790@kramden.acf.nyu.edu>
Date: 16 Dec 90 22:40:07 GMT
References: <6193:Dec618:43:4390@kramden.acf.nyu.edu> <1820@b15.INGR.COM> <2806@cirrusl.UUCP>
Organization: IR
Lines: 28

In article <2806@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
> I will make an even stronger statement than that:  There is no
> difference between an actual hole and a disk block full of zeroes.

If every hole on this system were allocated as a 0-filled block, we'd
need twice as many disks. Another system has a huge page size and
loosely padded executables; it would need three times as many disks.

If every 0-filled block on this system were made into a hole, several
well-written programs would crash miserably as soon as the disk is full.

> If we are picky we
> can even ask whether our data fits in the space available on disk, and
> this is why me might (vaguely) want to be aware that some data storage
> schemes (e.g. holes in files) are more efficient than others (e.g. zero
> bytes in files).

Yes, this is what st_blocks in stat is for.

> But for any specific file, at any specific offset in
> the file, we should not be asking such this question.

Oh? I have a file open. I want to make sure that blocks 17 through 22
(expressed in byte sizes) will be guaranteed not to run out of space
when I write to them. You're saying that I should have no way to make
this guarantee.

---Dan