🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.aos
Article #44

Re: The *real* file size (was: How to find *real* file sizes in AOS/VS...?)

#44
From: Michael Meissner
Date: Sat, 14 Oct 1989 01:26
53 lines
3223 bytes
>  From: kohli@gemed (Jim Kohli, but my friends call me)
>  Newsgroups: comp.os.aos
>  Keywords: AOS/VS filesize fubar
>  Date: 22 Sep 89 20:08:47 GMT
>  Reply-To: kohli@gemed.med.ge.com (Jim Kohli, but my friends call me)
>  Organization: GE Medical (Applied Science Lab)
>  
>  > 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.  

Wrong.  If you actually write an element's worth of zeros, you will
get a block allocated on the disk.  If you call ?ALLOCATE it will
allocate blocks on the disk.  The only way you get holes is by:

    1)	You do a ?SPOS to a location that is at least an element-
	size beyond the current end of the file;  or

    2)	You run a 32-bit program that ?SPAGES more than a couple
	of pages (I forget what the threshold is between where
	the system allocates the pages for you, and where the
	pages are not created until you touch them).  I'm not
	entirely positive about this last case.

The linker will use ?SPOS when linking common sections together that
don't have any initializations.  All of the DUMP/LOAD commands will
check for zero blocks and not write the blocks on the tape, and use
?SPOS to create the hole.  I'm not sure about COPY.

The newer DUMP commands will use the ?BLKIO system call to bypass any
holes in a file, while the older DUMP and early versions of DUMP_II
would become CPU intensive (the kernel would realize that the element
was not on disk, and zero fill the page -- meanwhile DUMP would then
rapidly search the page to see if it contained all zeros, and if it
did, chuck it out the window).  On my development system, we once had
a 40+ Meg file that had been created by a bad ?SPOS (the file was only
about 1 Meg), it it took quite some time before the system load went
back to normal.

Normal disclaimer -- I only speak for myself, and not for Data General
--

Michael Meissner, Data General.				If compiles where much
Uucp:		...!mcnc!rti!xyzzy!meissner		faster, when would we
Internet:	meissner@dg-rtp.DG.COM			have time for netnews?
Technical Details
Message-ID: <MEISSNER.89Oct13212615@tiktok.rtp.dg.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!mcnc!rti!xyzzy!meissner
References: <1055@mrsvr.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!mcnc!rti!xyzzy!meissner
From: meissner@dg-rtp.dg.com (Michael Meissner)
Newsgroups: comp.os.aos
Subject: Re: The *real* file size (was: How to find *real* file sizes in AOS/VS...?)
Message-ID: <MEISSNER.89Oct13212615@tiktok.rtp.dg.com>
Date: 14 Oct 89 01:26:15 GMT
References: <1055@mrsvr.UUCP>
Sender: usenet@xyzzy.UUCP
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 52
In-reply-to: kohli@gemed's message of 22 Sep 89 20:08:47 GMT