Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!phri!marob!cowan
From: cowan@marob.MASA.COM (John Cowan)
Newsgroups: comp.unix.wizards
Subject: Re: Releasing blocks from a file
Keywords: file truncation, getting rid of disk blocks, random seeks
Message-ID: <681@marob.MASA.COM>
Date: 19 May 89 19:52:09 GMT
References: <461@anvil.oz>
Reply-To: cowan@marob.masa.com (John Cowan)
Organization: ESCC  New York City
Lines: 43

In article <461@anvil.oz> michi@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@marob.masa.com> or <cowan@magpie.masa.com>
UUCP mailers:  ...!uunet!hombre!{marob,magpie}!cowan
Fidonet (last resort): 1:107/711
Aiya elenion ancalima!