Releasing blocks from a file

[John Cowan]

In article <461 at anvil.oz> michi at anvil.oz (Michael Henning) writes:
>
>I would like to know why [truncate()] has not been generalised to allow
>*any* block of a file to be released. For example, in random access files
>such as B-trees, on deletion, one would like to get rid of a disk block.
>Because there is no way to "shrink" a file under UNIX, B-tree packages are
>forced to either keep a list of free'd blocks for reuse, or to copy the entire
>tree to get rid of the unused space. Is there any reason not to have a system
>call something like:
>
>	release(fd, offset, num_blocks)
>	int fd;
>	off_t offset;
>	unsigned num_blocks;
>
>The idea is to specify that num_blocks are to be released beginning at
>the specified offset (which must be aligned on a file system block boundary).

The idea may be a good one, but I don't like the syntax/semantics of
this call.  It is better not to embed into programs knowledge about how big
a "block" is.  Here's a different proposed function:

	nullify(int fd; long size)

(note ANSI-ism) which causes "size" null bytes to be written to the file
at the current position.  The kernel then computes which blocks, if any,
can be freed, and which blocks must have actual zero bytes written in them
(at most two, the one at the beginning of the nullified region and the one
at the end).

Note that this does not remove the need for B-tree and suchlike programs
to keep their own free-lists.  There is no other way to know which parts of
your space are semantically empty and which parts contain information.
It simply avoids taking up more disk space than necessary.

Also note that this operation is fundamentally different from truncate(),
which changes the >size< of a file.  These operations change the content of
a file, not its size.
-- 
John Cowan <cowan at marob.masa.com> or <cowan at magpie.masa.com>
UUCP mailers:  ...!uunet!hombre!{marob,magpie}!cowan
Fidonet (last resort): 1:107/711
Aiya elenion ancalima!