sparse files

[Michael Meissner]

In article <2700 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:

|  >UNIX treats the "holes" as 0's when read. In fact, UNIX has only
|  >minimal support for sparse files.  Backing up sparse files often
|  >involves copying large amounts of nulls.  Once an area of a file is
|  >written, it cannot be returned to its previous sparse state.
|  
|  Not in general, anyway.  At least the first version of AIX for the RT PC
|  claimed, in its documentation, that it had an "fclear()" call to punch
|  holes in files; I think this may show up in future releases of other
|  UNIXes as well.
|  
|  >In arguments that UNIX is not suitable for DP applications, sparse
|  >files usually come up if the conversation goes on long enough between
|  >knowledgeable people.
|  
|  Umm, what other operating systems support sparse files *and* return a
|  "there's a hole there" indication?  For instance, are there any OSes
|  with extent-based file systems (VMS, OS/360 and successors as I
|  remember, IRIX with SGI's Extent File System) that support sparse files?

Data General's AOS/VS and AOS/VS-II operating systems support sparse
files, and recently they added a version of the read block system call
that would indicate where the holes are.  The default read and read
block system calls just return all zeroes.  Both the file level backup
programs, and the low level disk copy programs preserve holes.

Actually the user level backup programs will never write blocks of all
0's to the backup media (unlike either tar or cpio).  Before the
system call to tell where the holes were added, you could watch the
backup program get into a tight CPU loop when it would be processing a
large host (say a couple of meg of so).  The OS would realize that
there was a hole, and fill the buffer with all 0's, the dump program
would then compare the block to see if it contained all 0's, and if it
did skip it, maintaining the file position internally so it could then
be indicated when the next real data was encountered.
--
--
Michael Meissner, Data General.
Until 12/15:	meissner at dg-rtp.DG.COM
After 12/15:	meissner at osf.org