Path: utzoo!attcan!telly!eci386!jmm
From: jmm@eci386.uucp (John Macdonald)
Newsgroups: comp.unix.wizards
Subject: Re: Releasing blocks from a file
Keywords: file truncation, getting rid of disk blocks, random seeks
Message-ID: <1989May19.151448.1484@eci386.uucp>
Date: 19 May 89 15:14:48 GMT
References: <461@anvil.oz>
Reply-To: jmm@eci386.UUCP (John Macdonald)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 54

In article <461@anvil.oz> michi@anvil.oz (Michael Henning) writes:
>
>4.3 BSD has a truncate() system call ...
>I would like to know why this has not been generalised to allow
>*any* block of a file to be released. ...
>... 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;
>
>...
>
>					Michi.

There is one very good reason - the size of a block is not constant.
Some systems have a single system-wide block size (but different
instances might use different sizes), and other systems can support
different block sizes for different file systems simultaneously.

The end of file position is kept as a byte offset, and its position
relative to the underlying block layout used is handled by the file
system code.  To handle the block layout mapping transparently for
a release call could be done, but would be painfull.  To use your
suggested system/file-system dependent format would lead to obscure
bugs when the program gets the block size wrong, and to awkward code
to determine when a partial block release means that the entire block
could now being released.

Any method chosen that has user code based upon the underlying mapping
of bytes in a file to the physical storage units would interfere with
the freedom to make future changes in that mapping.  (If your proposed
release call above had been in effect early enough, there would have
been much more difficulty in going from 512 byte blocks to larger blocks.
If it came into effect somewhat later, there would have much more difficulty
in introducing file-system-switch and per-file-system-blocksize alternatives.)

A workable mechanism would be to have the system calls:
    release(int fd, off_t offset, off_t num_bytes)     and
    frelease(FILE *fp, off_t offset, off_t num_bytes)
(or a version without the offset argument that work relative to the current
seek position would be usable alternatives)

which would only guarantee that future reads of the file will return
all null bytes within the specified range, while permitting the kernel
to release any full blocks within the range, and possibly (if the kernel
implementors were ambitious) also release blocks that overlap the ends
of the range which have become entirely null bytes as after the required
zeroing.  The only difference between this and (seek to offset, write
num_byte long null buffer) would be the strong hint to the kernel that
blocks ought to be released.