Re: [Simh] Adding storage to vax running 4.3BSD
On 2017-05-12 01:15, Sergey Oboguev wrote: 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. Right. 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. I said MSCP and DSI. I was more referring to the DSI part of it, which is why I also was talking about SATA and SAS, and not ATA and SCSI. I guess I was sloppy in my writing again. 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 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
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
On 2017-05-11 22:52, Clem Cole wrote: On Thu, May 11, 2017 at 4:37 PM, Johnny Billquist mailto:b...@softjar.se>> 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
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
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
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. 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
> 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
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