holes in files
Dan Bernstein
brnstnd at kramden.acf.nyu.edu
Mon Dec 17 09:40:07 AEST 1990
In article <2806 at cirrusl.UUCP> dhesi%cirrusl at 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
More information about the Comp.unix.internals
mailing list