The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] Happy birthday, core dumped
Date: Wed, 18 Jun 2014 17:21:38 -0400 (EDT)	[thread overview]
Message-ID: <20140618212138.03B9218C13A@mercury.lcs.mit.edu> (raw)

    > From: "A. P. Garcia" <a.phillip.garcia at gmail.com>

    > that's like asking george martin for his source regarding a beatles
    > song...

Reminds me of the person on Wikipedia who tried to argue with me about the
'History of the Internet' article... :-)


    > From: John Cowan <cowan at mercury.ccil.org>

    >> scj at yaccman.com scripsit:

    >> a Dec repair person who ran "preventive maintenance" on our disc that
    >> wiped out the file system! His excuse was that Dec didn't support
    >> "permanent storage" on the disc at the time...

    > Next time, mount a scratch monkey.

It was probably a fixed-head disk (RS11 or RS04); can't exactly stick a
different pack in! :-) Probably the DEC OS's only used it for swapping or
something, since they were both relatively small - 512KB.

(Speaking of RS11's: the first PDP-11 I used - an 11/20 running RSTS - had a
grand total disk storage of _one_ RS11!)


And speaking of putting file systems on them: I recently wrote this command
for V6 called 'si' which allowed me (among many other interesting things) to
watch the contents of the disk buffer(s). It turns out that even with other
packs mounted, the buffer is almost always completely full of blocks from the
root device; it makes plain the value of having the root on a _really_
fast disk. 

I don't know if that usage pattern is because /bin is there, or because pipes
get created on the root, or what. When I get up the energy I'll move /bin to
another drive (yeah, yeah, I know - good way to lose and create a systen that
won't boot, so I'll actually make a _copy_ of /bin and mount it _over_ the
original /bin - probably a host of interesting errors there, e.g. if a process
has the old /bin as its current dir), and see what the cache contents look
like then.

	Noel



             reply	other threads:[~2014-06-18 21:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 21:21 Noel Chiappa [this message]
2014-06-18 22:55 ` John Cowan
  -- strict thread matches above, loose matches on Subject: below --
2014-06-20 13:05 Douglas Comer
2014-06-19  1:49 Doug McIlroy
2014-06-18 17:48 Douglas Comer
2014-06-18 22:38 ` Cory Smelosky
2014-06-18 15:03 Norman Wilson
2014-06-18 14:00 ` Larry McVoy
2014-06-18 16:58   ` Cory Smelosky
2014-06-18 15:55     ` Larry McVoy
2014-06-18 15:14 ` Dan Cross
2014-06-18 16:50 ` scj
2014-06-18 18:43   ` John Cowan
2014-06-18 11:06 Doug McIlroy
2014-06-18 14:43 ` iking
2014-06-18 14:48   ` Dan Cross
2014-06-18 18:21   ` A. P. Garcia
2014-06-15 18:19 Norman Wilson
2014-06-16 16:13 ` iking
2014-06-16 22:01   ` Gregg Levine
2014-06-17  1:38     ` John Cowan
2014-06-17  1:56       ` Greg 'groggy' Lehey
2014-06-17  3:13       ` iking
2014-06-17 12:14         ` John Cowan
2014-06-18 16:21           ` Ian King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140618212138.03B9218C13A@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).