> From: Random832
> They're 24 bits, aren't they?
Not according to the source:
typedef long daddr_t;
daddr_t s_fsize; /* size in blocks of entire volume */
short s_nfree; /* number of addresses in s_free */
daddr_t s_free[NICFREE];/* free block list */
(from param.h and filsys.h respectively).
> From: Ron Natalie
> The V6 block numbers were 24 bits.
Maybe you're thinking of the byte number within the file? The file length
was stored in an word plus a byte in the inode in V6:
char i_size0;
char *i_size1;
but the block number in the device was a word:
int s_fsize; /* size in blocks of entire volume */
int s_nfree; /* number of in core free blocks (0-100) */
int s_free[100]; /* in core free blocks */
"Use the source, Luke!"
Noel
> From: Will Senn
> Is there a good source of information about the Unix v6 filesystem
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man5/fs.5
> Also, is there a source for the history of the early Unix filesystems
> from v6 onward?
I don't know of one (although there is that article on the 4.2 filesystem),
but would love to hear of one.
I gather that V7 is basically V6 except the block numbers are 32 bits, not 16.
Noel
On Sun, Feb 21, 2016 at 09:21:14PM -0600, Will Senn wrote:
> Thanks for the link. The tools look useful. But, they appear to be extract from tape rather than create tape utils? I am away from a computer but will try them out later to make sure.
No, my bad. I thought they would make tapes, but I read the Readme files
and it doesn't look so. You could modify the mkfs.c tool that I wrote at
https://github.com/DoctorWkt/unix-jun72/blob/master/tools/mkfs.c
to write V6 filesystems. It shouldn't be too hard.
Cheers, Warren
Sometime back before the turn of the century, I remember
writing up a summary of the evolution of the UNIX file
system, starting with the earliest system I could find
information for (possibly the PDP-7 system) and running
through the printed manuals as things changed, up to
the Seventh Edition.
I think I've found it; I'll look it over and try to put
it somewhere on the web in the next day or two.
Norman Wilson
Toronto ON
> From: Will Senn
> Thanks for the link.
Sure. It's worth reading the entire V6 manual if you're going to be doing a
lot with it - lots of goodies hidden in places like that. Also the two BSTJ
Unix issues. (I think they are available online, now.)
> Supposing I created a byte faithful representation of a V6 filesystem
> on my mac, would I then be able to load the file in simh as an RK05 and
> mount and access its files and directories from a V6 instance?
That's really a SIMH question, and I don't use SIMH; I use Ersatz11. That is
certainly how Ersatz11 works; I just FTP'd the RK05 distro images over, set
them up as the files that 'implemented' various RK05 drives, and (modulo a
few teething Ersatz11 configuration issues) away it went.
Noel
> From: Random832
> That's the superblock. Look in ino.h.
Oh, right you are. Thanks for catching my mistake! (I don't have anything
like the same familiarity with V7 as I do with V6; never did any system
hacking on the former.)
Now that you mention it, I do seem to remember this kludge; IIRC, a later
Unix paper described the V7 inode layout. I never looked at the actual code,
though. Now that I do, it looks like iexpand() (in iget.c) is not exactly
portable! On a machine with a different byte order for the bytes within a
long, that ain't gonna work...
Noel
Hi all, Norman Wilson has kindly scanned in some PDP-7 Unix
source code that he has kept hidden away. I've just added
it into the Unix Archive at:
http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/
I've updated the Readme with the details. The files are 0*.pdf.
I'm not sure if there's enough there to bring up a kernel and
some applications. I'll leave that to someone who knows PDP-7
assembly programming :-)
Many thanks Norman!
Cheers, Warren
Of some possible intertest to the denizens here...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
---------- Forwarded message ----------
Date: Mon, 15 Feb 2016 07:11:44 +1100 (EST)
From: Dave Horsfall <dave(a)horsfall.org>
To: Applix List
Subject: APPLIX-L On this day... (Wirth, Feynman)
We gained Niklaus Wirth, otherwise known as Mr ALGOL (and thereby freeing
us from the chains of FORTRAN), back in 1934; you can either call him by
name, or call him by value (non-programmers are not expected to understand
this computer joke).
Upon the other paw, we lost Richard Feynman, back in 1988; he was the
bloke who sorted out those NASA management liars, over that little O-ring
incident... Well, that's what happens when the suits ignore the
engineers.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
John von Neumann halted in 1957; without him, we probably would not have
had computers as we know them (CPU-buss-memory etc).
--
Dave Horsfall
Unit 13, 79 Glennie St
North Gosford NSW 2250
0490 095 371