Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Releasing blocks from a file
Keywords: file truncation, getting rid of disk blocks, random seeks
Message-ID: <1661@auspex.auspex.com>
Date: 20 May 89 06:01:09 GMT
References: <461@anvil.oz>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 29

>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.

They depended on being able to do something like that, and the hack used
prior to that - open a new file, copy the first N bytes of the old file
to that file, close the files, and rename the new file on top of the old
file (or some such), was kind of gross and slow.

>I would like to know why this has not been generalised to allow
>*any* block of a file to be released.

In the case of 4.3BSD, perhaps nobody got around to it, and not enough
people asked for it to push somebody into getting around to it?

I think AIX has precisely such a function, called "fclear"; it's defined
to zero out a specific range of bytes in the file, and will do so by
putting "holes" into the files whenever it can.

This may appear in S5R4 under the guise of F_FREESP, as may the
"ftruncate" function. 

Provision for a "punch a hole in a file" function of that sort also
appears in drafts of the NFS Version 3 protocol; if the file system
can't punch holes in the file, it must write zeroes to that region of
the file.  (The same would presumably be true of local file systems put
under the S5R4 VFS mechanism that can't support files with holes; I
think, for instance, SGI's extent-based file system doesn't support
holes.)