[TUHS] Unix v6 File System information

[TUHS] Unix v6 File System information

[Noel Chiappa]

    > 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

[TUHS] Unix v6 File System information

[Dave Horsfall]

On Sun, 21 Feb 2016, Noel Chiappa wrote:

> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man5/fs.5

Yeah, but I was unsure whether the OP wanted a technical description, or 
one in plain English :-)  I'm still prepared to do the latter, once I can 
find a spare hour.

Somewhere, deep within Minnie's bowels, there might be a paper that I 
wrote upon implementing a "bad block" system (specifically directed at the 
RK-05, but generally applicable to any device); it involved the hitherto- 
unused inode "0", to which were chained the bad blocks (added by hand).

The trick was that normal FS utilities would ignore it...

Someone at the time (Kevin Hill?) pointed out that inode "-1" could also 
be used, but I wasn't prepared to go that far :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Unix v6 File System information

[Will Senn]

A technical description would be appreciated although the manpage looks like a good start as does Lions. I hadn't gotten to chapter 20 yet, should have known he would cover the topic.

Sent from my iPhone

> On Feb 21, 2016, at 7:34 AM, Dave Horsfall <dave at horsfall.org> wrote:
> 
>> On Sun, 21 Feb 2016, Noel Chiappa wrote:
>> 
>> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man5/fs.5
> 
> Yeah, but I was unsure whether the OP wanted a technical description, or 
> one in plain English :-)  I'm still prepared to do the latter, once I can 
> find a spare hour.
> 
> Somewhere, deep within Minnie's bowels, there might be a paper that I 
> wrote upon implementing a "bad block" system (specifically directed at the 
> RK-05, but generally applicable to any device); it involved the hitherto- 
> unused inode "0", to which were chained the bad blocks (added by hand).
> 
> The trick was that normal FS utilities would ignore it...
> 
> Someone at the time (Kevin Hill?) pointed out that inode "-1" could also 
> be used, but I wasn't prepared to go that far :-)
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Unix v6 File System information

[John Cowan]

Dave Horsfall scripsit:

> Somewhere, deep within Minnie's bowels, there might be a paper that I 
> wrote upon implementing a "bad block" system (specifically directed at the 
> RK-05, but generally applicable to any device); it involved the hitherto- 
> unused inode "0", to which were chained the bad blocks (added by hand).

The RSX-11 file system, later known as ODS-1, was similar in this respect:
the root directory contained entries for the bad-block file (BADBLK.SYS),
the inode-file-equivalent (INDEXF.SYS) and even itself (000000.DIR).

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
                I am a member of a civilization. --David Brin

[TUHS] Unix v6 File System information

[Dave Horsfall]

On Sun, 21 Feb 2016, John Cowan wrote:

> The RSX-11 file system, later known as ODS-1, was similar in this 
> respect: the root directory contained entries for the bad-block file 
> (BADBLK.SYS), the inode-file-equivalent (INDEXF.SYS) and even itself 
> (000000.DIR).

Ah, but my idea (never implemented, because disk drives got beyond ye olde 
RK-05) was that it never appeared as a directory entry.

Thus, Shell utilities would never see those blocks, and "dump" would never 
see them either, because it "knew" that inodes started at 1...  The only 
way you would see them was via a raw disk copy.

But, as I said, times moved on from the RK-05 (and the RP-04, and other 
air-exposed packs), thus my idea was dead.

Mind you, these "IBM PC" thingie drives are pretty awful at times :-)

And as for SSDs, don't ask, because they won't tell you about bad blocks; 
they are merely quietly remapped on the side[*].

[*]

I've been doing a fair bit of reading on these things.  Did you know that, 
for example, up to half the available silicon is dedicated towards the bad 
sectors that always crop up?  And the thing won't even tell you when it 
remaps a bad sector[#]?  It's because, amongst other things, that what you 
and I think of as a "block" is actually a huge chunk, so one bad bit in a 
cell could cause up to something like 64KB to be remapped.

In other words, if you knew how SSDs worked, you wouldn't stake your balls 
on them; they're just a large USB stick (and we know how cheaply they're 
made).

[#]

Because the proprietary on-board controller is saying "Everything's OK, 
boss!" whilst madly emptying a swampful of alligators.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Unix v6 File System information

[Lyndon Nerenberg]

> On Feb 21, 2016, at 5:58 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> Because the proprietary on-board controller is saying "Everything's OK, 
> boss!" whilst madly emptying a swampful of alligators.

This is no different from any "SMART" rusty drive.

[TUHS] Unix v6 File System information

[Tony Finch]

Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> > On Feb 21, 2016, at 5:58 PM, Dave Horsfall <dave at horsfall.org> wrote:
> >
> > Because the proprietary on-board controller is saying "Everything's OK,
> > boss!" whilst madly emptying a swampful of alligators.
>
> This is no different from any "SMART" rusty drive.

The SMART diagnostics data ought to tell you about reallocated sectors,
and apparently this is actually useful in practice.

https://www.backblaze.com/blog/hard-drive-smart-stats/

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Easterly or northeasterly 4 or 5, becoming variable 3 or 4 at
times. Moderate or rough, but smooth or slight in shelter in far southeast.
Occasional rain. Moderate or good, occasionally poor.

[TUHS] Unix v6 File System information

[Will Senn]

Sent from my iPhone

On Feb 21, 2016, at 5:44 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> 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


Thanks for the link. Let me ask a follow up question. 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? If I need to post in the SimH list, let me know.

Will

[TUHS] Unix v6 File System information

[Warren Toomey]

On Sun, Feb 21, 2016 at 09:36:12AM -0600, Will Senn wrote:
> Thanks for the link. Let me ask a follow up question. 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? If I need to post
> in the SimH list, let me know.
> Will

Yes. When we brought up the 1972 Unix kernel, I wrote a C tool to make and
populate the filesystem as a disk image, which we could then attach to SimH.
See mkfs.c in https://github.com/DoctorWkt/unix-jun72/tree/master/tools

Cheers, Warren

[TUHS] Unix v6 File System information

[Random832]

On Sun, Feb 21, 2016, at 06:44, Noel Chiappa wrote:
> I gather that V7 is basically V6 except the block numbers are 32 bits,
> not 16.

They're 24 bits, aren't they?

[TUHS] Unix v6 File System information

[ron]

The V6 block numbers were 24 bits.    The differences with V7 were the
larger block addresses, a slightly different way in which the block
addresses were encoded in the inode (no more large bit), and the expansion
of uid and gid to 16 bits from 8.

[TUHS] Unix v6 File System information

[Norman Wilson]

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

[TUHS] Unix v6 File System information

[Larry McVoy]

I did some work on the Unix file system:

http://www.sunhelp.org/history/pdf/unix_filesys_extent_like_perf.pdf

I spent a lot of time in bmap and it's amazing how much of the original
design still was there after BSD and Sun.  I diffed the code, bmap was
pretty much bmap after all those years.

On Sun, Feb 21, 2016 at 08:54:26PM -0500, Norman Wilson wrote:
> 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

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Unix v6 File System information

[Noel Chiappa]

    > 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

[TUHS] Unix v6 File System information

[Noel Chiappa]

    > 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

[TUHS] Unix v6 File System information

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]

​Will Senn asked

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

​Not 100% sure how to parse this... but that is exactly how simh (and
Ersatz11)​

​ work.
You have a UNIX file on your mac and at the simh interactive command
system, you "attach" it as the data for the simulated RK05.
​But it's a manual process to do the attachment AND more importantly,
since Mac OSx just sees it as bits, as a minimum you need to write tools to
push/pull V6 "files" from the image.  This is the same as the "DOS Tools"
trick you see in a lot of UNIX systems that know how to "grok" DOS/FAT file
system images.   You would need to do the same thing.  If you poke around
the Warren's TUHS archives, you might find some of this already there.

​What many of us do it attach a file as a virtual disk but instead of using
a UNIX file system format, use it is a tape image.   Then use tar/cpio or
whatever if you already a tool on both sides that can interpret the bits.
Hence, the v6tar discussion of a few weeks ago.   The UNIX ar(1) format is
sometimes used also, since it was common.   cpio -c also works, but that
was not on the research systems.​   My old room mate, Tom Quarles, wrote a
really good ANSI tape reader/writer for BSD UNIX.  That should back port to
v6 with a little work, particularly if you the "typesetter C" compiler for
V6 which supported enough of the V7 C.   The advantage of the ANSI tape
format is that its common with the DEC systems as well as UNIX.


That said, you can be smarter and more automatic.   As Noel says Ersatz11
supports a virtual shared disk (the same way VMware and Parallels) do.
Writing such a device for simh would be cool and in fact useful for many
different emulators.  Warning there are a lot of dragons hidden with such a
shared FS.   At is definitely doable, but is going to take some work.

The other thing you could do that might be a little less work, but would be
Mac specific, is Mac OSX has the FUSE file system emulation that stuff that
Google released.  If hacked up support for the old Unix FS, you could mount
the V6 "disk" image as Mac OSx disk and see the bits with normal tools.
I've thought about doing this but I have never had the time.  If I ever
became a serious user of the simh, I would probably want something more
like this.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160221/883e0385/attachment-0001.html>

[TUHS] Unix v6 File System information

[arnold]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]

Already been done: see http://osxbook.com/software/ancientfs/

Arnold

Clem Cole <clemc at ccc.com> wrote:

> ​Will Senn asked
>
> > 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?
> >
>
> ​Not 100% sure how to parse this... but that is exactly how simh (and
> Ersatz11)​
>
> ​ work.
> You have a UNIX file on your mac and at the simh interactive command
> system, you "attach" it as the data for the simulated RK05.
> ​But it's a manual process to do the attachment AND more importantly,
> since Mac OSx just sees it as bits, as a minimum you need to write tools to
> push/pull V6 "files" from the image.  This is the same as the "DOS Tools"
> trick you see in a lot of UNIX systems that know how to "grok" DOS/FAT file
> system images.   You would need to do the same thing.  If you poke around
> the Warren's TUHS archives, you might find some of this already there.
>
> ​What many of us do it attach a file as a virtual disk but instead of using
> a UNIX file system format, use it is a tape image.   Then use tar/cpio or
> whatever if you already a tool on both sides that can interpret the bits.
> Hence, the v6tar discussion of a few weeks ago.   The UNIX ar(1) format is
> sometimes used also, since it was common.   cpio -c also works, but that
> was not on the research systems.​   My old room mate, Tom Quarles, wrote a
> really good ANSI tape reader/writer for BSD UNIX.  That should back port to
> v6 with a little work, particularly if you the "typesetter C" compiler for
> V6 which supported enough of the V7 C.   The advantage of the ANSI tape
> format is that its common with the DEC systems as well as UNIX.
>
>
> That said, you can be smarter and more automatic.   As Noel says Ersatz11
> supports a virtual shared disk (the same way VMware and Parallels) do.
> Writing such a device for simh would be cool and in fact useful for many
> different emulators.  Warning there are a lot of dragons hidden with such a
> shared FS.   At is definitely doable, but is going to take some work.
>
> The other thing you could do that might be a little less work, but would be
> Mac specific, is Mac OSX has the FUSE file system emulation that stuff that
> Google released.  If hacked up support for the old Unix FS, you could mount
> the V6 "disk" image as Mac OSx disk and see the bits with normal tools.
> I've thought about doing this but I have never had the time.  If I ever
> became a serious user of the simh, I would probably want something more
> like this.
>
> Clem

[TUHS] Unix v6 File System information

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]

I've tried to use ancientfs, but couldn't get it to work. Other fuse 
FSes, yes, ancientfs, no.

On 2/21/16 1:31 PM, arnold at skeeve.com wrote:
> Already been done: see http://osxbook.com/software/ancientfs/
>
> Arnold
>
> Clem Cole <clemc at ccc.com> wrote:
>
>> ​Will Senn asked
>>
>>> 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?
>>>
>> ​Not 100% sure how to parse this... but that is exactly how simh (and
>> Ersatz11)​
>>
>> ​ work.
>> You have a UNIX file on your mac and at the simh interactive command
>> system, you "attach" it as the data for the simulated RK05.
>> ​But it's a manual process to do the attachment AND more importantly,
>> since Mac OSx just sees it as bits, as a minimum you need to write tools to
>> push/pull V6 "files" from the image.  This is the same as the "DOS Tools"
>> trick you see in a lot of UNIX systems that know how to "grok" DOS/FAT file
>> system images.   You would need to do the same thing.  If you poke around
>> the Warren's TUHS archives, you might find some of this already there.
>>
>> ​What many of us do it attach a file as a virtual disk but instead of using
>> a UNIX file system format, use it is a tape image.   Then use tar/cpio or
>> whatever if you already a tool on both sides that can interpret the bits.
>> Hence, the v6tar discussion of a few weeks ago.   The UNIX ar(1) format is
>> sometimes used also, since it was common.   cpio -c also works, but that
>> was not on the research systems.​   My old room mate, Tom Quarles, wrote a
>> really good ANSI tape reader/writer for BSD UNIX.  That should back port to
>> v6 with a little work, particularly if you the "typesetter C" compiler for
>> V6 which supported enough of the V7 C.   The advantage of the ANSI tape
>> format is that its common with the DEC systems as well as UNIX.
>>
>>
>> That said, you can be smarter and more automatic.   As Noel says Ersatz11
>> supports a virtual shared disk (the same way VMware and Parallels) do.
>> Writing such a device for simh would be cool and in fact useful for many
>> different emulators.  Warning there are a lot of dragons hidden with such a
>> shared FS.   At is definitely doable, but is going to take some work.
>>
>> The other thing you could do that might be a little less work, but would be
>> Mac specific, is Mac OSX has the FUSE file system emulation that stuff that
>> Google released.  If hacked up support for the old Unix FS, you could mount
>> the V6 "disk" image as Mac OSx disk and see the bits with normal tools.
>> I've thought about doing this but I have never had the time.  If I ever
>> became a serious user of the simh, I would probably want something more
>> like this.
>>
>> Clem

[TUHS] Unix v6 File System information

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]

It has not been updated since about 10.5 so I'm not surprised.

On Sun, Feb 21, 2016 at 3:45 PM, Will Senn <will.senn at gmail.com> wrote:

> I've tried to use ancientfs, but couldn't get it to work. Other fuse FSes,
> yes, ancientfs, no.
>
>
> On 2/21/16 1:31 PM, arnold at skeeve.com wrote:
>
>> Already been done: see http://osxbook.com/software/ancientfs/
>>
>> Arnold
>>
>> Clem Cole <clemc at ccc.com> wrote:
>>
>> ​Will Senn asked
>>>
>>> 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?
>>>>
>>>> ​Not 100% sure how to parse this... but that is exactly how simh (and
>>> Ersatz11)​
>>>
>>> ​ work.
>>> You have a UNIX file on your mac and at the simh interactive command
>>> system, you "attach" it as the data for the simulated RK05.
>>> ​But it's a manual process to do the attachment AND more importantly,
>>> since Mac OSx just sees it as bits, as a minimum you need to write tools
>>> to
>>> push/pull V6 "files" from the image.  This is the same as the "DOS Tools"
>>> trick you see in a lot of UNIX systems that know how to "grok" DOS/FAT
>>> file
>>> system images.   You would need to do the same thing.  If you poke around
>>> the Warren's TUHS archives, you might find some of this already there.
>>>
>>> ​What many of us do it attach a file as a virtual disk but instead of
>>> using
>>> a UNIX file system format, use it is a tape image.   Then use tar/cpio or
>>> whatever if you already a tool on both sides that can interpret the bits.
>>> Hence, the v6tar discussion of a few weeks ago.   The UNIX ar(1) format
>>> is
>>> sometimes used also, since it was common.   cpio -c also works, but that
>>> was not on the research systems.​   My old room mate, Tom Quarles, wrote
>>> a
>>> really good ANSI tape reader/writer for BSD UNIX.  That should back port
>>> to
>>> v6 with a little work, particularly if you the "typesetter C" compiler
>>> for
>>> V6 which supported enough of the V7 C.   The advantage of the ANSI tape
>>> format is that its common with the DEC systems as well as UNIX.
>>>
>>>
>>> That said, you can be smarter and more automatic.   As Noel says Ersatz11
>>> supports a virtual shared disk (the same way VMware and Parallels) do.
>>> Writing such a device for simh would be cool and in fact useful for many
>>> different emulators.  Warning there are a lot of dragons hidden with
>>> such a
>>> shared FS.   At is definitely doable, but is going to take some work.
>>>
>>> The other thing you could do that might be a little less work, but would
>>> be
>>> Mac specific, is Mac OSX has the FUSE file system emulation that stuff
>>> that
>>> Google released.  If hacked up support for the old Unix FS, you could
>>> mount
>>> the V6 "disk" image as Mac OSx disk and see the bits with normal tools.
>>> I've thought about doing this but I have never had the time.  If I ever
>>> became a serious user of the simh, I would probably want something more
>>> like this.
>>>
>>> Clem
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160221/50b1e6f5/attachment.html>

[TUHS] Unix v6 File System information

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5151 bytes --]



On 2/21/16 12:59 PM, Clem Cole wrote:
>
> ​ Will Senn asked
>
>     > 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?
>
>
> ​ Not 100% sure how to parse this... but that is exactly how simh (and 
> Ersatz11)​
> ​ work.
> You have a UNIX file on your mac and at the simh interactive command 
> system, you "attach" it as the data for the simulated RK05.
> ​ But it's a manual process to do the attachment AND more importantly,
> since Mac OSx just sees it as bits, as a minimum you need to write 
> tools to push/pull V6 "files" from the image. This is the same as the 
> "DOS Tools" trick you see in a lot of UNIX systems that know how to 
> "grok" DOS/FAT file system images.   You would need to do the same 
> thing. If you poke around the Warren's TUHS archives, you might find 
> some of this already there.
>
> ​What many of us do it attach a file as a virtual disk but instead of 
> using a UNIX file system format, use it is a tape image.   Then use 
> tar/cpio or whatever if you already a tool on both sides that can 
> interpret the bits.   Hence, the v6tar discussion of a few weeks ago. 
>   The UNIX ar(1) format is sometimes used also, since it was common.   
> cpio -c also works, but that was not on the research systems.​   My 
> old room mate, Tom Quarles, wrote a really good ANSI tape 
> reader/writer for BSD UNIX.  That should back port to v6 with a little 
> work, particularly if you the "typesetter C" compiler for V6 which 
> supported enough of the V7 C.   The advantage of the ANSI tape format 
> is that its common with the DEC systems as well as UNIX.
>
>
> That said, you can be smarter and more automatic.   As Noel says 
> Ersatz11 supports a virtual shared disk (the same way VMware and 
> Parallels) do.   Writing such a device for simh would be cool and in 
> fact useful for many different emulators.  Warning there are a lot of 
> dragons hidden with such a shared FS.   At is definitely doable, but 
> is going to take some work.
>
> The other thing you could do that might be a little less work, but 
> would be Mac specific, is Mac OSX has the FUSE file system emulation 
> that stuff that Google released.  If hacked up support for the old 
> Unix FS, you could mount the V6 "disk" image as Mac OSx disk and see 
> the bits with normal tools.   I've thought about doing this but I have 
> never had the time.  If I ever became a serious user of the simh, I 
> would probably want something more like this.
>
> Clem
>

Thanks Clem. I know that in theory, this should be super 
straightforward, but it seems that theory and reality are uncomfortable 
with each other around me and this question. I've tried maybe 7 dozen 
different approaches to getting 1bsd.tar.gz files to be accessible to v6 
with more than a handful of files at a time. The vast majority of these 
methods were flawed in their conception, but some "should have worked" 
by all accounts, and yet, no joy (pun intended). I can use the paper 
tape punch method or others to copy one file at a time, but that's 
tedious. All of the other methods folks have suggested, I've tried, but 
frustratingly, it just doesn't seem possible to perform the "back in the 
day" install of 1bsd on v6:

Berkeley UNIX Software Tape
     Jan 16, 1978    TP 800BPI

     To extract contents do:
       tp xm ./setup; sh setup; tp xm

     See accompanying document
Second label on the tape:

     The contents of this tape are
     distributed to UNIX licensees
     only, subject to the software
     agreement you have with Western
     Electric and an agreement with
     the University of California.


For example, it seems like using tar2mt on the gunzipped tarball and 
attaching to tm0 should work, but when running tp xm on it, it fails 
(something about directory checksum). I know the tarball is good, not so 
sure about the mt image (tried it with default blocksize and 512 as well).

In the absence of positive confirmation of someone else's successful 
experience installing 1bsd, I backburner this problem every so often and 
carry on with my other investigations. When someone suggests something 
new, or I think of some new angle, I fire up the sim and try installing 
again. Hence, my occasional queries that seem to be retreads.

Now that I have more experience with the SimH simulator, PDP-11 
architecture/programming, and success at moving files around DEC OS'es, 
I feel oh so close to a breakthrough on this one sticky problem :). 
Hence my latest interest in the file system. I figure if I can 
understand the format I may be able to check the conversion of the 
tarball to a v6 consumable filesystem and determine why it's not working.

Why, oh why, didn't someone save a tape image, rather than a tarball, 
given that tar on v6 was so hokey?!

Thanks,

Will





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160221/c63c3802/attachment-0001.html>

[TUHS] Unix v6 File System information

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

On Sun, Feb 21, 2016 at 4:05 PM, Will Senn <will.senn at gmail.com> wrote:

> Why, oh why, didn't someone save a tape image, rather than a tarball,
> given that tar on v6 was so hokey?!


​hmm - no idea.  I don't remember having had such problems to be honest.
Maybe we can find the a tp image.   I'm sure they reason they used a tar
image was, that tp was  more problematic​.

That said, I still think the tar image should work.   Maybe the solution is
try to compiler stp with a modern C compiler.  It will take some work to
move it I suspect because the code would be 100% assuming PDP-11 in every
way, and is binary.  Plus things like stat.h are a bit different than in
the old days.   Let's take this off-line and let see what's possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160221/d86d9107/attachment.html>

[TUHS] Unix v6 File System information

[Warren Toomey]

On Sun, Feb 21, 2016 at 03:05:39PM -0600, Will Senn wrote:
>    Why, oh why, didn't someone save a tape image, rather than a tarball,
>    given that tar on v6 was so hokey?!
>    Thanks,
>    Will

In http://www.tuhs.org/Archive/PDP-11/Tools/Tapes/
there are tools that I and other wrote to create
tape images: tp etc.

So you could do:

	tar vxf 1bsd.tar
	tp tool to build a tp image
	mktap to build a SimH tap image
	attach to SimH
	PROFIT!!

So sorry, I couldn't stop myself.

Cheers, Warren

[TUHS] Unix v6 File System information

[Warren Toomey]

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

[TUHS] Unix v6 File System information

[Noel Chiappa]

    > 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

[TUHS] Unix v6 File System information

[Random832]

On Sun, Feb 21, 2016, at 12:50, Noel Chiappa wrote:
>     > 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).

That's the superblock. Look in ino.h.

/*
 * the 40 address bytes:
 *       39 used; 13 addresses
 *       of 3 bytes each.
 */

Which means you can't actually have a filesystem of more than 2^24-1
blocks.

[TUHS] Unix v6 File System information

[ron]

>     > From: Random832
>
>     > They're 24 bits, aren't they?
>
Yes, you're right.   V6 file length 24 bits, V6 block index 16
V7 added 8 bits to both.

[TUHS] Unix v6 File System information

[Will Senn]

All,

Is there a good source of information about the Unix v6 filesystem 
outside of the source code itself? Also, is there a source for the 
history of the early Unix filesystems from v6 onward?

Thanks,

Will

[TUHS] Unix v6 File System information

[Dave Horsfall]

On Sun, 21 Feb 2016, Will Senn wrote:

> Is there a good source of information about the Unix v6 filesystem 
> outside of the source code itself? Also, is there a source for the 
> history of the early Unix filesystems from v6 onward?

Well, I could tell you exactly how the V6 FS worked, but it would take me 
over an hour to type it all in, so hopefully someone will come forward.

Dir entry: 14 chars (non-null term), plus 16 bit index into inode.

Inode table: a bit weird, involving single/double/triple block addresses 
into the disk itself.

And then we have the superblock (yep, only one, in those days).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Unix v6 File System information

[Jacob Ritorto]

On Sun, Feb 21, 2016 at 5:01 AM, Dave Horsfall <dave at horsfall.org> wrote:

>
> Well, I could tell you exactly how the V6 FS worked, but it would take me
> over an hour to type it all in, so hopefully someone will come forward.
>

How about a description / story about it on youtube :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160304/30d25403/attachment.html>

[TUHS] Unix v6 File System information

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Fri, 4 Mar 2016, Jacob Ritorto wrote:

>       Well, I could tell you exactly how the V6 FS worked, but it would 
>       take me over an hour to type it all in, so hopefully someone will 
>       come forward.
> 
> How about a description / story about it on youtube :) 

I don't do "social media", sorry...  Someone will have a copy of the Lions
book, though.

Hey, someone could make a video of it; I'm sure that Dr. John Lions 
would've condoned it :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Unix v6 File System information

[SPC]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

I got the reedition of Lion's book. Very cool.

About a youtube exposition... perhaps. But it would take some time.

Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations
​
-- 
*Sergio Pedraja*
-- 
twitter: @sergio_pedraja | skype: Sergio Pedraja
--
http://plus.google.com/u/0/101292256663392735405
http://www.linkedin.com/in/sergiopedraja
-----
No crea todo lo que ve, ni crea que está viéndolo todo


2016-03-10 9:51 GMT+01:00 Dave Horsfall <dave at horsfall.org>:

> On Fri, 4 Mar 2016, Jacob Ritorto wrote:
>
> >       Well, I could tell you exactly how the V6 FS worked, but it would
> >       take me over an hour to type it all in, so hopefully someone will
> >       come forward.
> >
> > How about a description / story about it on youtube :)
>
> I don't do "social media", sorry...  Someone will have a copy of the Lions
> book, though.
>
> Hey, someone could make a video of it; I'm sure that Dr. John Lions
> would've condoned it :-)
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160310/3840d0be/attachment.html>

[TUHS] Unix v6 File System information

[arnold]

Will Senn <will.senn at gmail.com> wrote:

> All,
>
> Is there a good source of information about the Unix v6 filesystem 
> outside of the source code itself? Also, is there a source for the 
> history of the early Unix filesystems from v6 onward?
>
> Thanks,
>
> Will

The Lyons book would be where I'd go to look.  

Arnold

[TUHS] Unix v6 File System information

[Dave Horsfall]

On Sun, 21 Feb 2016, arnold at skeeve.com wrote:

> The Lyons book would be where I'd go to look.  

Lions, if you don't mind (I knew him personally).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Unix v6 File System information

[arnold]

> On Sun, 21 Feb 2016, arnold at skeeve.com wrote:
>
> > The Lyons book would be where I'd go to look.  

Dave Horsfall <dave at horsfall.org> wrote:
> Lions, if you don't mind (I knew him personally).

My bad. I beg your pardon. :-)

When Peter Salus et al arranged to publish it I bought a copy and
read it, and enjoyed it thoroughly.

I also have one of the proverbial "n-th generation photocopies" made
circa 1984 (+/- a year), but I did not read it at the time.

Arnold

[TUHS] Unix v6 File System information

[Clement T. Cole]

Also check out the MIT fall OS course notes.  They ported v6 to the x86 and have course notes with some good detail.  I'm not near my real computer so I don't have the URL handy where I am. If you send me an email off list I'll be happy to pass it on. It's in one of my quora replies so you can google there and find it also

Clem

Sent from my iPad

> On Feb 21, 2016, at 8:54 AM, arnold at skeeve.com wrote:
> 
> 
>>> On Sun, 21 Feb 2016, arnold at skeeve.com wrote:
>>> 
>>> The Lyons book would be where I'd go to look.  
> 
> Dave Horsfall <dave at horsfall.org> wrote:
>> Lions, if you don't mind (I knew him personally).
> 
> My bad. I beg your pardon. :-)
> 
> When Peter Salus et al arranged to publish it I bought a copy and
> read it, and enjoyed it thoroughly.
> 
> I also have one of the proverbial "n-th generation photocopies" made
> circa 1984 (+/- a year), but I did not read it at the time.
> 
> Arnold

[TUHS] Unix v6 File System information

[Dave Horsfall]

On Sun, 21 Feb 2016, arnold at skeeve.com wrote:

> > > The Lyons book would be where I'd go to look.  
> 
> > Lions, if you don't mind (I knew him personally).
> 
> My bad. I beg your pardon. :-)

No problem; a lot of people get it wrong :-)  He was one of my CompSci
lecturers.

> When Peter Salus et al arranged to publish it I bought a copy and read 
> it, and enjoyed it thoroughly.

And I proof-read it, and helped him print it (you'll find my name in the 
back).

> I also have one of the proverbial "n-th generation photocopies" made 
> circa 1984 (+/- a year), but I did not read it at the time.

The most photo-copied book in the world :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."