Path: 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: 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 > 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?