Path: utzoo!attcan!telly!lethe!torsqnt!jarvis.csri.toronto.edu!mailrus!uwm.edu!csd4.csd.uwm.edu!mrsvr.UUCP!kohli@gemed.med.ge.com
From: kohli@gemed (Jim Kohli, but my friends call me)
Newsgroups: comp.os.aos
Subject: The *real* file size (was: How to find *real* file sizes in AOS/VS...?)
Keywords: AOS/VS filesize fubar
Message-ID: <1055@mrsvr.UUCP>
Date: 22 Sep 89 20:08:47 GMT
Sender: news@mrsvr.UUCP
Reply-To: kohli@gemed.med.ge.com (Jim Kohli, but my friends call me)
Organization: GE Medical (Applied Science Lab)
Lines: 75

> Richard Alan Brown @ Comp Sci, Melbourne Uni, Australia notes:
>	But I have noticed DG's sneaky compression of files
>(executables) with large blocks of nulls in them (am I right?),
>so that a file can seem large (in bytes), while actually taking
>up much less disk space. (Is this only for PRV files?  Why
>doesn't the file system tell users the 'correct' size?)
>
AOS/VS "compresses" *ANY* kind of file which has a complete
"element" (i.e., contiguous disk allocation) of zeroes.  This
happens to save disk space -- and it does have some advantages
which I think outweigh the disadvantages.  This is also one
reason DG discourages make .PR files contiguous-- although you
may get faster page faulting, you will take up more disk
space-- although it may be worth the tradeoff.
Why doesn't the file system tell you the 'correct' size?  It
doesn't know!  What is the 'correct' size, after all?  The size
which AOS/VS gives you is the amount of space that the data *IN*
the file would occupy if it had no compression applied to it.  This
number should be treated as the size of the file in all cases
where disk space allocation is not critical.  Obviously, if a
file is contiuous, and has any non-zero data it it, the only
space it will occupy is directory overhead space.
If you really need to find out exactly how much space is
occupied by a single file, your best recourse is to create
a CPD, make a junk file in it (to init the directory),
delete the junk file, *NOW* note the space in the directory,
move your file into it and note the difference in space.
This method will not work for a series of files unless you
recreate the CPD for each file (because the directory
overhead space is not reclaimed).

>Now for the *really* tricky part. Create an empty CPD. put a
>file in it (length 0). Start adding data. Who knows how much
>space the file takes up!?
>
You are pretty close-- see the above...

>  Does the SPACE command include the
>space taken up by directory entries?
>
You betcha

> How does one calculate
>that (Note that when one deletes the file, the CPD is not
>'empty'. This presumably is the directory entry...?).
>
Correct, again!

How bad do you need to know?

Dumping stuff won't really do much because the same "rule of
compression" applies to dumpfiles.

DG gets a lot of flack from people who really need to know
how much space their file is really taking, and I believe
their method is "make CPD, make junk file, delete junk
file, write down space, move file into CPD, subtract new
space from old space".

Jim

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
decrepitate: 1. to roast or calcine (salt, minerals, etc.) so as to
cause crackling or until crackling ceases...

In a context: "Oh, my brain is decrepitating!  Aaaaaaarrrgggghh!!!!"
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Jim Kohli                    | "Oh Grammar!  Water bag icer gut!
GE Medical Systems           | A nervous sausage bag ice!"
PO Box 414                   |
Milwaukee, WI	53201-414    |
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
gemed!hal!kohli@crd.ge.com
sun!sunbird!gemed!hal!kohli
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""