Very Computer

Here's something interesting.  What do you think caused this?  Why the
discrepancy in sizes? (2Gb, but only 160 disk blocks.)

Script started on Sat Feb  2 16:16:43 1991
warning: could not update utmp entry
1 phoenix:~/src/snatch/foo ls -l core
-rw-r--r--  1 pfalstad 2013290928 Feb  2 16:14 core
2 phoenix:~/src/snatch/foo stat core
  File: "core"
  Size: 2013290928   Allocated Blocks: 160          Filetype: Regular File
  Mode: (0644/-rw-r--r--)         Uid: ( 3564/pfalstad)  Gid: (   35/ student)
Device: -32255  Inode: 19078     Links: 1    
Access: Sat Feb  2 16:14:45 1991
Modify: Sat Feb  2 16:14:09 1991
Change: Sat Feb  2 16:14:13 1991
3 phoenix:~/src/snatch/foo exit
exit

script done on Sat Feb  2 16:17:51 1991

I created this by playing around with the PTRACE_DUMPCORE instruction to
ptrace(2).  We're using SunOS 4.1.1.

--

"And she's always on about men following her.  I don't know what she
thinks they're going to do to her.  Vomit on her, Basil, says."-Flowery*s

Well, one school of thought says that this is a quite unreasonable way
to make core files---or any files---when the holes are so easy to avoid.
It's remarkable how often users accidentally fill up disks under SunOS
by copying or otherwise processing those core files. It's also quite a
waste of time to do ``strings'' on a 2GB file with practically nothing
but nulls; if the same information were stored in 160K, things would run
a lot faster.

---Dan
Stupidity, n.: An overwhelming desire to rewrite one-line shell scripts
as 36-line Perl scripts so they run 6% faster. See Christiansen, Tommy.

My bet is that there are very large unallocated holes in the file.
That's one reasonable way to make core files.  If this is true, then
the total file size (2GB) represents the whole possible address
space of the program, and the allocated blocks (160) represents how
much memory the program was actually using.

Not being familiar with SunOS, I can't say for certain, though.

--

DG/UX Kernel Development         UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC, USA  These opinions are mine, not DG's.

Quote:> Here's something interesting.  What do you think caused this?  Why the
> discrepancy in sizes? (2Gb, but only 160 disk blocks.)

        On some occasions (when creating core for example), SUNOS filesystem
        is able to detect blocks filled with zeros and make decision:

        - This block is all zero, so remember that, and not allocate
          real block for it now.

        If file is copied (cp core xx) it expands to full size (quite *
        sometimes).

--

Pertti Lehtinen                         ! purely offending and in subject
Tampere University of Technology        ! to change without any further
Software Systems Laboratory             ! notice

hunt> My bet is that there are very large unallocated holes in the file.
hunt> That's one reasonable way to make core files.

Dan> Well, one school of thought says that this is a quite unreasonable way
Dan> to make core files---or any files---when the holes are so easy to avoid.
Dan> It's remarkable how often users accidentally fill up disks under SunOS
Dan> by copying or otherwise processing those core files.

One could argue, quite reasonably, that this is a problem with cp.
Allowing files with holes is a nice feature of UNIX. That some tools
have not been designed to process them should not discourage their use.

Dan> It's also quite a
Dan> waste of time to do ``strings'' on a 2GB file with practically nothing
Dan> but nulls; if the same information were stored in 160K, things would run
Dan> a lot faster.

Never had any problems with this.

/Lars
--

CS Dept., Univ. of Aalborg, DENMARK. |                   - FZ

Quote:>Dan> It's remarkable how often users accidentally fill up disks under SunOS
>Dan> by copying or otherwise processing those core files.

[It's also remarkable how much disk space is saved by putting "limit
core 0" in users' initial .login files.]

Quote:>One could argue, quite reasonably, that this is a problem with cp.
>Allowing files with holes is a nice feature of UNIX. That some tools
>have not been designed to process them should not discourage their use.

If you put the solution in cp, you have to put it in every other
program that essentially copies a file (cat, tar, tr ...).  If you
want the problem solved for all such programs, the thing to do is to
have the kernel always leave holes for all-zero blocks (you could also
partially solve it by putting it in stdio).  This has disadvantages -
it would slow writing files a little in the usual case, and it would
mean that if you wanted to preallocate file space you'd have to use
something other than zeros.

Quote:>Dan> Well, one school of thought says that this is a quite unreasonable way
>Dan> to make core files---or any files---when the holes are so easy to avoid.

I certainly think Sun made a mistake here.  But on the other hand, they
make money from selling disk, don't they :-)

-- Richard
--


Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin