Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!munnari!murtoa.cs.mu.oz.au!bruce!goanna!chudich!rcodi
From: rcodi@chudich.co.rmit.oz (Ian Donaldson)
Newsgroups: comp.unix.wizards
Subject: Re: Releasing blocks from a file
Keywords: file truncation, getting rid of disk blocks, random seeks
Message-ID: <508@chudich.co.rmit.oz>
Date: 20 May 89 04:43:12 GMT
References: <461@anvil.oz>
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 45

In article <461@anvil.oz>, michi@anvil.oz (Michael Henning) writes:
> 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 would prefer to see num_blocks be in terms of bytes, not blocks.  A block
size is filesystem dependent (although fstat(2) and stat(2) on BSD tell
you how large it is).
Also no other current UNIX system calls take arguments in terms of blocks.

Of course if you release the space in a file on byte boundaries that
do not fall exactly on block boundaries then some blocks won't be releaseable,
hence the call will have a lesser effect than intended.

If the semantics of the call were right, it would be possible to 
implement ftruncate() as a library call that uses release() internally.

Also it would be possible to implement infinite length FIFO's as ordinary
files.  You could release the space at the *beginning* of the file after
it has been read.  You might need extra support to determine where the
new logical beginning of the file *is* however.  Its FIFO use may be limited
by the fact that the new logical start position would be limited to a
block boundary unless FIFO byte pointers were installed in the inode or 
something, which probably means creating a new FIFO file type (as opposed 
to named pipes).  The implimentation could be similar to that of named pipes.
But named pipes would differ in that the data is lost after a reboot or
close.  named fifo's would retain the data like ordinary files.
In fact you could even implement named pipes as a special case of
named fifo's.  (cf: BSD that does it as a special case of sockets)

This is all tied in with the ability to copy holey files around, which 
is a facility that is also currently lacking.

eg: dump/tar/cpio/cp could use this facility *now* and make themselves
more functional and portable:  dump would no longer be required to read 
raw filesystems to get the info.  cp would no longer allocate more disk
space in the destination of a holey file copy.

Ian D