Re: [Simh] Adding storage to vax running 4.3BSD

[Sergey Oboguev]

 Johnny Billquist wrote: 
> Well, MSCP was a good solution, and it's rather funny to now watch SATA 
> and SAS, which is almost a carbon copy of MSCP and DSI, but 20 years later.

Unless I am mistaken, SCSI (at least in the form of SASI) preceded MSCP 
chronologically and perhaps inspired the latter.
SAS thus would have no need for MSCP as an intellectual ancestor, although for 
sure technologies of the same field, such as storage technologies, mutually 
inform each other in the course of their development.
  ___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Adding storage to vax running 4.3BSD

[Johnny Billquist]

On 2017-05-11 23:02, Bob Eager wrote:

On Thu, 11 May 2017 22:37:59 +0200
Johnny Billquist  wrote:


On 2017-05-11 15:34, Paul Koning wrote:



On May 11, 2017, at 9:24 AM, Jason Stevens
 wrote:

Ah now that makes more sense!

On May 11, 2017 5:11:34 AM GMT+08:00, Alan Perry
 wrote:

Problem solved. Apparently this kernel doesn't know about RA82s. I
changed them to RA81 and it worked fine.

alan


Yikes.  The whole point of MSCP was to make the software not care
about device sizes or geometry.  It's amazing to see Unix get it so
badly wrong.


True. However, it isn't actually the geometry that cause the Unix
messup here, but the fact that Unix divided disks into partitions. So
it needed to know where each partition started. And before
disklabels, it was hardcoded per disk type.


The origin of the partitioning goes back to the introduction of the
RP03.

UNIX had been written as a 16 bit system, and when we got ours (1975)
it was on RK05s, which only had about 5000 blocks. We moved on to
RP02s, which were again OK, as they were only about 40,000 blocks, and
that number fitted into a 16 bit unsigned integer.

All of UNIX was built round 16 bit values, and it was a major change to
adapt to anything larger. But then the RP03 arrived - around 80,000
blocks; too big.

The solution - minimal work - was to partition the disk into two fixed
pieces (virtual RP02s if you like) at the driver level, and present the
pieces as separate disks to the rest of the system. Very little else
needed modification, although the whole disk was exposed as another
device.

One thing that did have to be fixed was the 'seek' system call, which
couldn't seek over the whole disk as it only handled 16 bits. This was
needed for low level operations on the disk. The solution was to have a
'long seek' system call, which took a bigger offset value. That
survives to this day as 'lseek'.

This kludge was 'justified' as a good way to divide functionality of
the disk, but it was really a kludge!


Right. But that in the end still means that the problem was the 
partitioning, not the disk geometry abstraction, layout and size, which 
is what MSCP addressed.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Adding storage to vax running 4.3BSD

[Johnny Billquist]

On 2017-05-11 22:52, Clem Cole wrote:


On Thu, May 11, 2017 at 4:37 PM, Johnny Billquist > wrote:

True. However, it isn't actually the geometry that cause the Unix
messup here, but the fact that Unix divided disks into partitions.
So it needed to know where each partition started. And before
disklabels, it was hardcoded per disk type.

​To be fair


Well...


UNIX partition the RP06 because it overflowed a 16bit integer on the
PDP-11.The 36 bits machines DEC was making at the same time did have
that problem.Because UNIX supported mounted file systems which most
small computer systems could not, ​it was a fairly elegant solution.


The DEC OSes did not suffer this problem (or rather, some of them 
didn't, RT-11 do have this limitation). Just because the word size of 
the PDP-11 is 16 bits you did not have to limit the size of a file 
system to 16 bit block numbers. And in the DEC OSes, mounted file 
systems were something available to all, and not just privileged 
users... (And yes, you did need to mount file systems.) Are you making a 
comparison to systems like CP/M?


Not sure I understand the 36-bit comment, unless it was a typo for 16 
bits...


Also, with 16 bits, the maximum size of a disk would be 32M, which you 
hit already with the RP04 or RM03. RP06 is massively larger than that, 
at 167M.



Like many software tricks that were introduced to solve one issue, it
was a handy solution for others and partitions became de rigor for
quotas, organization and other sins.   The commercial UNIX vendors put
labels and support in the disk ROMS pretty early, (PC/UNIX's was ham
strung by the sins of IBM) but its a classic example of things are the
way there are because it made a lot of sense when it was done.   Time
moved on


True in its way, but at the same time not everyone was doing it, so the 
excuse that such were the times are a pretty weak argument.



And as Paul and I were discussing off-line 'support' for MSCP really was
not a 'mess-up' -- it was a zip/zag where DEC went one direction and by
that time it came out, BSD was trying to solve a problem different than
what DEC's cared about and non-DEC UNIX vendors started having their own
solution.

So while its an example of the start of DEC HW being to quit being the
'focus' for things UNIX.  It was a cool new thing DEC had, but
basically it was minimally supported, not exploited, because people did
not care at the point.


Well, MSCP was a good solution, and it's rather funny to now watch SATA 
and SAS, which is almost a carbon copy of MSCP and DSI, but 20 years later.


But I think it's mostly a red herring talking about MSCP while on this 
subject. MSCP was trying to solve one problem. The partition table thing 
in Unix was for addressing a different problem, so MSCP or not don't 
really matter here.


Once you had the partition tables, you had a problem with unknown disks, 
no matter what the controller and interface to the disks look like.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Adding storage to vax running 4.3BSD

[Bob Eager]

On Thu, 11 May 2017 22:37:59 +0200
Johnny Billquist  wrote:

> On 2017-05-11 15:34, Paul Koning wrote:
> >  
> >> On May 11, 2017, at 9:24 AM, Jason Stevens
> >>  wrote:
> >>
> >> Ah now that makes more sense!
> >>
> >> On May 11, 2017 5:11:34 AM GMT+08:00, Alan Perry
> >>  wrote:
> >>
> >> Problem solved. Apparently this kernel doesn't know about RA82s. I
> >> changed them to RA81 and it worked fine.
> >>
> >> alan  
> >
> > Yikes.  The whole point of MSCP was to make the software not care
> > about device sizes or geometry.  It's amazing to see Unix get it so
> > badly wrong.  
> 
> True. However, it isn't actually the geometry that cause the Unix
> messup here, but the fact that Unix divided disks into partitions. So
> it needed to know where each partition started. And before
> disklabels, it was hardcoded per disk type.

The origin of the partitioning goes back to the introduction of the
RP03.

UNIX had been written as a 16 bit system, and when we got ours (1975)
it was on RK05s, which only had about 5000 blocks. We moved on to
RP02s, which were again OK, as they were only about 40,000 blocks, and
that number fitted into a 16 bit unsigned integer.

All of UNIX was built round 16 bit values, and it was a major change to
adapt to anything larger. But then the RP03 arrived - around 80,000
blocks; too big.

The solution - minimal work - was to partition the disk into two fixed
pieces (virtual RP02s if you like) at the driver level, and present the
pieces as separate disks to the rest of the system. Very little else
needed modification, although the whole disk was exposed as another
device.

One thing that did have to be fixed was the 'seek' system call, which
couldn't seek over the whole disk as it only handled 16 bits. This was
needed for low level operations on the disk. The solution was to have a
'long seek' system call, which took a bigger offset value. That
survives to this day as 'lseek'.

This kludge was 'justified' as a good way to divide functionality of
the disk, but it was really a kludge!
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Adding storage to vax running 4.3BSD

[Clem Cole]

On Thu, May 11, 2017 at 4:37 PM, Johnny Billquist  wrote:

> True. However, it isn't actually the geometry that cause the Unix messup
> here, but the fact that Unix divided disks into partitions. So it needed to
> know where each partition started. And before disklabels, it was hardcoded
> per disk type.

​To be fair


UNIX partition the RP06 because it overflowed a 16bit integer on the
PDP-11.The 36 bits machines DEC was making at the same time did have
that problem.Because UNIX supported mounted file systems which most
small computer systems could not, ​it was a fairly elegant solution.

Like many software tricks that were introduced to solve one issue, it was a
handy solution for others and partitions became de rigor for quotas,
organization and other sins.   The commercial UNIX vendors put labels and
support in the disk ROMS pretty early, (PC/UNIX's was ham strung by the
sins of IBM) but its a classic example of things are the way there are
because it made a lot of sense when it was done.   Time moved on

And as Paul and I were discussing off-line 'support' for MSCP really was
not a 'mess-up' -- it was a zip/zag where DEC went one direction and by
that time it came out, BSD was trying to solve a problem different than
what DEC's cared about and non-DEC UNIX vendors started having their own
solution.

So while its an example of the start of DEC HW being to quit being the
'focus' for things UNIX.  It was a cool new thing DEC had, but basically it
was minimally supported, not exploited, because people did not care at the
point.

Clem

Clem
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Adding storage to vax running 4.3BSD

[Paul Koning]

> On May 11, 2017, at 9:24 AM, Jason Stevens  
> wrote:
> 
> Ah now that makes more sense!
> 
> On May 11, 2017 5:11:34 AM GMT+08:00, Alan Perry  wrote:
> 
> Problem solved. Apparently this kernel doesn't know about RA82s. I 
> changed them to RA81 and it worked fine.
> 
> alan

Yikes.  The whole point of MSCP was to make the software not care about device 
sizes or geometry.  It's amazing to see Unix get it so badly wrong.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Adding storage to vax running 4.3BSD

[Jason Stevens]

Ah now that makes more sense!

On May 11, 2017 5:11:34 AM GMT+08:00, Alan Perry  wrote:
>
>Problem solved. Apparently this kernel doesn't know about RA82s. I 
>changed them to RA81 and it worked fine.
>
>alan
>
>On 5/10/17 1:59 PM, Alan Perry wrote:
>> There is definitely some confusion here. But note that Bob brought up
>
>> disklabel, not me. I was pointing out that I could not follow the 
>> disklabel step in his instructions because there is no disklabel 
>> command in the root path on my 4.3 BSD (it says 4.3BSD in the motd
>and 
>> the login prompt).
>>
>> I already indicated that "newfs /dev/ra1c ra82" is responding:
>>  Don't have a parition table for a DU RA 82
>>  /dev/rra1c: cannot create
>>
>> I get the same partition message at boot time:
>>  ra1 at uda0 slave 1
>>  Don't have a parition table for a DU RA 82
>>  ra2 at uda0 slave 2
>>  Don't have a parition table for a DU RA 82
>>
>> I initially thought that this was a partition table in a disklabel, 
>> but it been explained to me that the layout is compiled into the 
>> kernel and there should be a matching entry in /etc/disktab. There 
>> wasn't one, so I created a disktab entry for ra82.
>>
>> alan
>>
>> On 5/10/17 1:38 PM, Anders Magnusson wrote:
>>> You have mixed up something here.
>>>
>>> There are no disklabels whatsoever in 4.3BSD, and nothing in newfs 
>>> that cares about it.
>>> If your newfs complains about disklabels, you are using newfs from 
>>> something else, not 4.3BSD.
>>>
>>> -- R
>>>
>>> Den 2017-05-10 kl. 21:15, skrev Alan Perry:
 Your instructions say to use disklabel. However, there is no 
 disklabel in the default root execution path on the 4.3 BSD image 
 that I am running.

 On 5/10/17 11:03 AM, Bob Eager wrote:
> If you look through those instructions I posted a link to, you'll
>see
> how to do a disklabel.
>
> On Wed, 10 May 2017 07:41:01 -0700
> Alan Perry  wrote:
>
>> I have tried to run newfs on partition c and it fails,
>complaining
>> about the lack of a partition table.
>>
>>> On May 10, 2017, at 07:29, Jason Stevens
>>>  wrote:
>>>
>>> If Im remembering right, straight 4.3 pre-dates the labels, it's
>a
>>> hard coded partition types in the drivers at this point.
>>>
>>> If you don't care, just use the 0c devices aka 'whole disk' ...
>or
>>> I recall that working well enough.
 --
 From:Alan Perry
 Sent:Wednesday, May 10, 2017 12:57 AM
 To:simh@trailing-edge.com
 Subject:[Simh] Adding storage to vax running 4.3BSD

 What are the steps for adding storage to a SIMH vax (vax750, to
>be
 specific) running 4.3BSD? I created disk image files on the
>host
 OS of the proper size (for RA82s) and attached them through
 the .ini file. However, they don't have partition tables and
>this
 version of BSD doesn't seem to have a tool for creating them.
>So,
 how do I put partition tables on the ra82 disk images?

 Thanks,

 alan

 ___
 Simh mailing list
 Simh@trailing-edge.com
 http://mailman.trailing-edge.com/mailman/listinfo/simh
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

 ___
 Simh mailing list
 Simh@trailing-edge.com
 http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>
>>
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>___
>Simh mailing list
>Simh@trailing-edge.com
>http://mailman.trailing-edge.com/mailman/listinfo/simh

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Adding storage to vax running 4.3BSD

[Anders Magnusson]

Den 2017-05-11 kl. 01:20, skrev Johnny Billquist:

On 2017-05-10 22:59, Alan Perry wrote:

There is definitely some confusion here. But note that Bob brought up
disklabel, not me. I was pointing out that I could not follow the
disklabel step in his instructions because there is no disklabel command
in the root path on my 4.3 BSD (it says 4.3BSD in the motd and the login
prompt).

I already indicated that "newfs /dev/ra1c ra82" is responding:
 Don't have a parition table for a DU RA 82


Right. There is no partition table for DU RA 82. That does not imply 
that it is looking for a disk label, but just indicates that the 
driver to not have a table for this drive.
The tables are (as Ragge mentioned earlier) compiled statically into 
the driver.

Yep, and the message comes from the kernel, not from newfs.

Alan, there are no problems to just add a partition tables for a larger 
MSCP disks to the driver (using diskpart).

Just edit vaxuba/uda.c and recompile the kernel :-)

-- R



Johnny


 /dev/rra1c: cannot create

I get the same partition message at boot time:
 ra1 at uda0 slave 1
 Don't have a parition table for a DU RA 82
 ra2 at uda0 slave 2
 Don't have a parition table for a DU RA 82

I initially thought that this was a partition table in a disklabel, but
it been explained to me that the layout is compiled into the kernel and
there should be a matching entry in /etc/disktab. There wasn't one, so I
created a disktab entry for ra82.

alan

On 5/10/17 1:38 PM, Anders Magnusson wrote:

You have mixed up something here.

There are no disklabels whatsoever in 4.3BSD, and nothing in newfs
that cares about it.
If your newfs complains about disklabels, you are using newfs from
something else, not 4.3BSD.

-- R

Den 2017-05-10 kl. 21:15, skrev Alan Perry:

Your instructions say to use disklabel. However, there is no
disklabel in the default root execution path on the 4.3 BSD image
that I am running.

On 5/10/17 11:03 AM, Bob Eager wrote:

If you look through those instructions I posted a link to, you'll see
how to do a disklabel.

On Wed, 10 May 2017 07:41:01 -0700
Alan Perry  wrote:


I have tried to run newfs on partition c and it fails, complaining
about the lack of a partition table.


On May 10, 2017, at 07:29, Jason Stevens
 wrote:

If Im remembering right, straight 4.3 pre-dates the labels, it's a
hard coded partition types in the drivers at this point.

If you don't care, just use the 0c devices aka 'whole disk' ... or
I recall that working well enough.

--
From:Alan Perry
Sent:Wednesday, May 10, 2017 12:57 AM
To:simh@trailing-edge.com
Subject:[Simh] Adding storage to vax running 4.3BSD

What are the steps for adding storage to a SIMH vax (vax750, to be
specific) running 4.3BSD? I created disk image files on the host
OS of the proper size (for RA82s) and attached them through
the .ini file. However, they don't have partition tables and this
version of BSD doesn't seem to have a tool for creating them. So,
how do I put partition tables on the ra82 disk images?

Thanks,

alan

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh




___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh





___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh