Path: utzoo!attcan!uunet!cs.utexas.edu!mailrus!ncar!boulder!sunybcs!sbcs!mjn
From: mjn@sbcs.sunysb.edu (The Sixth Replicant)
Newsgroups: comp.os.aos
Subject: Re: The *real* file size (was: How to find *real* file sizes in AOS/VS...?)
Keywords: AOS/VS filesize fubar
Message-ID: <3540@sbcs.sunysb.edu>
Date: 23 Sep 89 00:29:22 GMT
References: <1055@mrsvr.UUCP>
Sender: news@sbcs.sunysb.edu
Reply-To: mjn@sbstaff2.UUCP (The Sixth Replicant)
Organization: Tyrell Corp.
Lines: 23

In article <1055@mrsvr.UUCP> kohli@gemed.med.ge.com (Jim Kohli, but my friends call me) writes:
>AOS/VS "compresses" *ANY* kind of file which has a complete
>"element" (i.e., contiguous disk allocation) of zeroes.  This
>...

I just want to clarify one point here. AOS/VS doesn't do any compression.
The file system allows users to have unallocated blocks in files. When
read, these blocks will be returned as zeros. Certain commands (MOVE,
DUMP, DUMP_II) exploit this property to save space. If, however I write
an element of zeros to disk, I'll get an element of zeros on disk, the
file systems doesn't scan for zeros to see if it can optimize the write.
This would take far too much CPU.

I don't honestly know what UNIX does when I write to a high block number
in an empty file, but I'd be somewhat surprised if it doesn't allow for
unallocated blocks. The description of WRITE in "The design of the UNIX
Operating System" by Bach (p 101) suggests to me that the intervening
space is left unallocated. I think the difference between AOS/VS and
UNIX may be that AOS/VS provides the CPD is which you are told _exact_
space usage, where in UNIX you only have du, which I tend to suspect
doesn't give the precise number.
-----------------------------------------------------------------------------
Marc Neuberger                                            mjn@sbcs.sunysb.edu