public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: Valdis.Kletnieks@vt.edu
Cc: Hans Reiser <reiser@namesys.com>, linux-kernel@vger.kernel.org
Subject: Re: [IDEA] - run-length compaction of block numbers
Date: Sun, 08 Feb 2004 22:38:06 +1100	[thread overview]
Message-ID: <31255.1076240286@ocs3.ocs.com.au> (raw)
In-Reply-To: Your message of "Mon, 19 Jan 2004 11:20:51 CDT." <200401191620.i0JGKqKe012285@turing-police.cc.vt.edu>

On Mon, 19 Jan 2004 11:20:51 -0500, 
Valdis.Kletnieks@vt.edu wrote:
>I don't know how IBM did disk space management on the earlier systems
>such as the 1401, 7040, and 7090 series, but I'd suspect it was a similar
>extent-based method.

<old-fogey-mode>

Can't speak for the 1401 or 7xxx series.  IBM 1620[*], which was
obsolete back in 1977 when I programmed it, also used extent based disk
directories.  There were three directory areas on disk, one to map file
names to extent indexes, one to map the used extents on the disk and
one to map the free space extents.

[*] Binary coded decimal.  Each digit had 4 numeric bits plus two flag
    bits.  Two adjacent digits made a letter (and you thought that
    Unicode was bad!).  Card punch or paper tape in/out.  No printer,
    feed the cards through a separate machine for that.  20,000 digits
    of memory with a 2 Mb disk drive was a big machine.

    Five digit addressing with one nice feature, if the flag bit was
    set on the rightmost digit of an address then it was automatically
    treated as an indirect address and the real address was fetched
    from the area referenced by this address, the real address could
    also be flagged as indirect and the process would continue.  The
    IBM manual claimed that indirect addresses required no extra time
    (nothing changes about computer claims :).  The student's idea of
    fun was to load all of memory with indirect addresses, each
    pointing to the next with loop around.  Refer to the first and
    watch the big panel lights slowly cycle through all of memory doing
    nothing useful.

</old-fogey-mode>


  parent reply	other threads:[~2004-02-08 11:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-16 19:38 [IDEA] - run-length compaction of block numbers raymond jennings
2004-01-16 19:52 ` Randy.Dunlap
2004-01-16 19:54 ` Valdis.Kletnieks
2004-01-16 20:36   ` Ian Pilcher
2004-01-16 21:57     ` Mike Fedyk
2004-01-16 20:47   ` Hans Reiser
2004-01-16 22:38     ` Valdis.Kletnieks
2004-01-19 10:45       ` Hans Reiser
2004-01-19 16:20         ` Valdis.Kletnieks
2004-01-19 17:06           ` Hans Reiser
2004-02-08 11:38           ` Keith Owens [this message]
     [not found] <1eI8L-5fS-9@gated-at.bofh.it>
2004-01-16 20:01 ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2004-01-29 16:40 raymond jennings

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=31255.1076240286@ocs3.ocs.com.au \
    --to=kaos@ocs.com.au \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiser@namesys.com \
    /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