Article View: comp.os.aos
Article #44Re: The *real* file size (was: How to find *real* file sizes in AOS/VS...?)
From: Michael Meissner
Date: Sat, 14 Oct 1989 01:26
Date: Sat, 14 Oct 1989 01:26
53 lines
3223 bytes
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!meissnerReferences:
<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