Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!munnari!murtoa.cs.mu.oz.au!bruce!dbrmelb!dmsmelb!dmsbris!qfagus!anvil!michi
From: michi@anvil.oz (Michael Henning)
Newsgroups: comp.unix.wizards
Subject: Releasing blocks from a file
Keywords: file truncation, getting rid of disk blocks, random seeks
Message-ID: <461@anvil.oz>
Date: 17 May 89 10:13:05 GMT
Organization: Anvil Designs Pty Ltd, Brisbane, Australia
Lines: 33


4.3 BSD has a truncate() system call to get rid of trailing blocks at the end
of a file. I believe that this was introduced to allow certain FORTRAN
libraries to work under UNIX, which depended on that feature.
I would like to know why this 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).
I believe that all the kernel would have to do is to set the corresponding
pointers inthe file's inode to NULL and to return these blocks to the free list.
On a subsequent read of a block at that offset, the kernel could return
a block of NULL characters, just like for a file that was written with
random access and has no data in the region being read.

					Michi.


-- 
               | The opinions expressed are my own, not those of my employer. |
               |                                                              |
               | Michael (Michi) Henning                                      |
               | - We have three Michaels here, that's why they call me Michi |