Re: Origin of "partition" in storage devices

[jim stephens via cctalk]

On 1/31/2022 11:01 AM, Tom Gardner via cctalk wrote:



It seems clear it was used in memory well before HDDs but when it got
started there is unclear.
* IBM PC DOS v2 was an early user in 1983 with FDISK and its first PC
support of HDDs
* UNIX, Apple OS's and IBM mainframe all seem to come later.

We had a local grown OS which was really a way to file paper tapes on a 
disk with file pointers.  We had an allocation method, all the file 
system things, a VTOC (copied a lot of ibm terms).  Eventually added 
half inch tape.


This was on a Microdata 1621 minicomputer, and was named MPS, or 
Microdata Programming System.  We could take paper tape distributed 
software from Microdata, read them in and patch the terminal read / 
write and in the case of compilers, the paper tape read / write 
instructions and point them easily at our disk.


Anyway our files had a name and  disk pointer which essentially was the 
cylinder and sector of the file.  All was on a 2.5 mb platter using both 
surfaces of our the removable pack on the 5mb Western Dynex drive.


I added the capability to select surfaces which occurred when you booted 
the system and it would remember a surface system variable used by the 
disk routines that the programs didn't have to be concerned with. We 
could run from either platter this way with a copy of the system.


Used the other platter for storing an image and doing a backup. Before 
that time, we had not written any way to back up, so I built that up.


I later implemented a system to save out to tape, and rebuild and 
install to the disk.


Also could later when I worked at Microdata use multiple drive and do 
the copying as well as double sized disks.


There was a lot of odd data stored outside the disk space (allocated and 
free).


I implemented a small rotating log of when the disks were booted, a name 
for the disk system running you could query, and other information.


I don't know how this might fit into partitioning disks, but it did 
divide the two platter system into two separate file systems.  I never 
moved it to any hardware requiring more complication, but would have 
just added more indexing as to where the disk was mounted and what the 
volume was.


You'll note that our 2.5mb file system isn't much larger than two 1.4mb 
3 1/2" floppies, but we ran all the system software that we needed, 
system generation, sources and user files and easily had 20 to 25% of 
the space left over.  Much smaller systems back then.


Single user similar to a large high wattage PC I suppose.

The partitioning was implemented in 1972 (or dual platter backup).

BTW we had an entertaining file recovery and sort that ran on either 
platter.  We'd erase the "other" platter to no files, and then copy all 
the files in on the other volume to the alternate.  When you finished 
all of your files were sequential and not wasted space.


Our file system used linked sectors, and the free space was allocated by 
a linked list of sectors, not a bitmap.  The beginning of files were 
luckily odd enough that they could be recognized and another utility 
could recover all the files and rebuild the entire VTOC with nothing but 
the files present.  IMplemented over a couple of horrible days when the 
VTOC got erased.


thanks
Jim

Re: Origin of "partition" in storage devices

[Warner Losh via cctalk]

On Tue, Feb 1, 2022 at 5:32 PM Paul Koning  wrote:

>
>
> > On Feb 1, 2022, at 6:00 PM, Warner Losh via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > On Tue, Feb 1, 2022 at 12:42 PM Grant Taylor via cctalk <
> > cctalk@classiccmp.org> wrote:
> >
> >> On 2/1/22 2:14 AM, Joshua Rice via cctalk wrote:
> >>> There's several advantages to doing it that way, including balancing
> >>> wear on a disk (especially today, with SSDs), as a dedicated swap
> >>> partition could put undue wear on certain areas of disk.
> >>
> >> I thought avoiding this very problem was the purpose of the wear
> >> leveling functions in SSD controllers.
> >
> > All modern SSD's firmware that I'm aware of decouple the physical
> location
> > from the LBA. They implement some variation of 'append store log' that
> > abstracts out the LBAs from the chips the data is stored in. One big
> reason
> > for this is so that one worn out 'erase block' doesn't cause a hole in
> the
> > LBA
> > range the drive can store data on. You expect to retire hundreds or
> > thousands of erase blocks in today's NAND over the life of the drive, and
> > coupling LBAs to a physical location makes that impossible.
>
> Another reason is that the flash memory write block size is larger than
> the sector size exposed to the host, and the erase block size is much
> larger than the write block size.  So the firmware has to keep track of
> retired data, move stuff around to collect an erase block worth of that,
> then erase it to make it available again to receive incoming writes.
>

Yes. That larger sector size is the 'erase block' that I was talking about.
The whole garbage
collection of old data makes or breaks drive performance. There's a number
of techniques
that are used these days to hide it, though. The extra erase blocks that
are free are usual
SLC so can be written quickly (and for many work loads recently written
blocks are likely
to be rewritten soon, so when you GC the SLC pages, you're only doing small
portions of
them). This buffer of available blocks is one reason you need larger
capacity.

Another twist: Recently, NAND has a 16k-64k page size, which is one reason
you'll
see drives report an emulated size of 4k (since it has 4k LBAs), but a
native size of
16k or 64k. This helps drive provisioning software align partitions on a
boundary that
the drive is likely able to handle better.


> The spare capacity of an SSD can be pretty substantial.  I remember one
> some years ago that had a bug which, in a subtle way, exposed the internal
> structure of the device.  It turned out the exposed capacity was 49/64th of
> the physical flash space.  Strange fraction, I don't think we were ever
> told why, but the supplier did confirm we analyzed it correctly.
>

The other reason you'd need additional capacity is to meet the endurance
requirements
of the drive. If the vendor says it will last N years with M months of
retention and Z writes,
then you have to make sure that after Z writes some margin above your
capacity point
remains in service. You can usually only keep those blocks whose error
rates are low
enough that you can safely store data for M months on them in service, and
that gets
much harder at the end of life. Having a larger over provisioning, you can
increase
N, M or Z (but usually not all of them).

Warner

Re: OT: Who? What? Was: Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 6:46 PM, Jon Elson via cctalk  
> wrote:
> 
> On 2/1/22 15:40, Paul Koning via cctalk wrote:
>> 
>>> On Feb 1, 2022, at 4:31 PM, Grant Taylor via cctalk  
>>> wrote:
>>> 
>>> On 2/1/22 11:23 AM, Paul Koning via cctalk wrote:
 Did any DEC MSCP disks use it?
>>> Please expand "MSCP".  My brain is failing to do so at the moment.
>> Mass Storage Control Protocol, the geometry-independent storage access 
>> scheme DEC created in the early 1980s.  Early implementations include the 
>> HSC50 (for VAXclusters) and the UDA50 (Unibus adapter), talking to disk 
>> drives such as the RA80.
>> 
>> With MSCP, DEC switched to addressing disks by sector offset, as SCSI did 
>> later, rather than by geometry (cylinder, track, sector)
> 
> All SCSI devices were logical block number, all the way back to the original 
> SASI (Shugart Associates System Interface).  I had a 10 MB Memorex Winchester 
> drive with SASI adapter on my Z-80 CP/M system in about 1981 or so.  Maybe I 
> misunderstood your sentence above, what the "later" applied to.

I meant that SCSI appeared later than MSCP.  And that it used LBA addressing, 
but MSCP did it before SCSI.

paul

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 6:00 PM, Warner Losh via cctalk  
> wrote:
> 
> On Tue, Feb 1, 2022 at 12:42 PM Grant Taylor via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> On 2/1/22 2:14 AM, Joshua Rice via cctalk wrote:
>>> There's several advantages to doing it that way, including balancing
>>> wear on a disk (especially today, with SSDs), as a dedicated swap
>>> partition could put undue wear on certain areas of disk.
>> 
>> I thought avoiding this very problem was the purpose of the wear
>> leveling functions in SSD controllers.
> 
> All modern SSD's firmware that I'm aware of decouple the physical location
> from the LBA. They implement some variation of 'append store log' that
> abstracts out the LBAs from the chips the data is stored in. One big reason
> for this is so that one worn out 'erase block' doesn't cause a hole in the
> LBA
> range the drive can store data on. You expect to retire hundreds or
> thousands of erase blocks in today's NAND over the life of the drive, and
> coupling LBAs to a physical location makes that impossible.

Another reason is that the flash memory write block size is larger than the 
sector size exposed to the host, and the erase block size is much larger than 
the write block size.  So the firmware has to keep track of retired data, move 
stuff around to collect an erase block worth of that, then erase it to make it 
available again to receive incoming writes.

The spare capacity of an SSD can be pretty substantial.  I remember one some 
years ago that had a bug which, in a subtle way, exposed the internal structure 
of the device.  It turned out the exposed capacity was 49/64th of the physical 
flash space.  Strange fraction, I don't think we were ever told why, but the 
supplier did confirm we analyzed it correctly.

paul

Re: OT: Who? What? Was: Re: Origin of "partition" in storage devices

[Jon Elson via cctalk]

On 2/1/22 15:40, Paul Koning via cctalk wrote:



On Feb 1, 2022, at 4:31 PM, Grant Taylor via cctalk  
wrote:

On 2/1/22 11:23 AM, Paul Koning via cctalk wrote:

Did any DEC MSCP disks use it?

Please expand "MSCP".  My brain is failing to do so at the moment.

Mass Storage Control Protocol, the geometry-independent storage access scheme 
DEC created in the early 1980s.  Early implementations include the HSC50 (for 
VAXclusters) and the UDA50 (Unibus adapter), talking to disk drives such as the 
RA80.

With MSCP, DEC switched to addressing disks by sector offset, as SCSI did 
later, rather than by geometry (cylinder, track, sector)


All SCSI devices were logical block number, all the way back 
to the original SASI (Shugart Associates System Interface).  
I had a 10 MB Memorex Winchester drive with SASI adapter on 
my Z-80 CP/M system in about 1981 or so.  Maybe I 
misunderstood your sentence above, what the "later" applied to.


Jon

Re: Origin of "partition" in storage devices

[Warner Losh via cctalk]

On Tue, Feb 1, 2022 at 12:42 PM Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> On 2/1/22 2:14 AM, Joshua Rice via cctalk wrote:
> > There's several advantages to doing it that way, including balancing
> > wear on a disk (especially today, with SSDs), as a dedicated swap
> > partition could put undue wear on certain areas of disk.
>
> I thought avoiding this very problem was the purpose of the wear
> leveling functions in SSD controllers.
>

All modern SSD's firmware that I'm aware of decouple the physical location
from the LBA. They implement some variation of 'append store log' that
abstracts out the LBAs from the chips the data is stored in. One big reason
for this is so that one worn out 'erase block' doesn't cause a hole in the
LBA
range the drive can store data on. You expect to retire hundreds or
thousands of erase blocks in today's NAND over the life of the drive, and
coupling LBAs to a physical location makes that impossible.

Warner

Re: OT: Who? What? Was: Re: Origin of "partition" in storage devices

[Will Cooke via cctalk]

> On 02/01/2022 4:08 PM Chuck Guzis via cctalk  wrote:
> 
> 
> 

> Good grief, it took DEC all that time? CDC was doing it in the 1960s.
> Had to, because of the wide variety of RMS available. I think that
> one of the early 2311 clone drives (854?) used 256-byte (8 bit byte)
> hard-sectored media, which isn't very friendly to systems with 60 bit
> words. I recall that several sectors were used to create a logical
> 60-bit word addressable sector, with a substantial part of the last
> sector of a logical PRU left unused.
> 
> --Chuck

LTA predates that considerably and is the earliest I am aware of.

LTA (Logical Tooth Addressing) was created in the 1850's by Babbage to avoid 
the "shaft, gear, tooth" addressing he had been using in his "store."  The 
teeth of all gears were numbered sequentially (starting at 0 of course) across 
all the gears and shafts.  He even kept a few spare gears in a drawer for wear 
leveling.  

It's believed the idea actually originated with Ada since it made her task much 
easier.

Will

Re: Origin of "partition" in storage devices

[Chris Elmquist via cctalk]

On Tuesday (02/01/2022 at 01:41PM -0500), Chris Zach via cctalk wrote:
> > Which came first CLV CDs, or CLV LaserDiscs?
> 
> Laserdiscs by far. Only the very first models played CAV only.
> 
> CAV is nice because you can freeze frame without a frame buffer.

Yes!  My dad did some of the first work on LaserDiscs-- built 3Ms plant
for making them in the late 70s.

As a result, we always had "samples" from the production line to watch
at home and numerous different players to check out.

CAV allowed you to freeze frame, step forward and back and never loose
frame sync.  You had a solid picture no matter whether it was playing,
stepping or paused.  But, you also got at most about 30 mins / side on
a disc and so a movie was 3 or 4 discs in length.

With CLV, you got more on the disc, about an hour per side or a whole
movie on one disc but you could not smoothly pause or step it.  Some
players would completely disallow it and some would display the torn
image with pieces from multiple adjacent frames.

CAV was used a lot for educational discs where the player was controlled
by a computer (in one case we had, a Sony CP/M machine) which combined
the interactive educational software on the computer with video content on
the disc.  The Sony computer had a genlock system in it so that it could
overlay computer graphics on the video signal from the disc player.

This was 1979 or 1980 if I remember correctly.

Chris
-- 
Chris Elmquist

Re: OT: Who? What? Was: Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 5:08 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 2/1/22 13:40, Paul Koning via cctalk wrote:
>> 
> 
>> With MSCP, DEC switched to addressing disks by sector offset, as SCSI did 
>> later, rather than by geometry (cylinder, track, sector) on devices like the 
>> RK05 and RP06.  If the OS sees only an LBA, it doesn't matter whether the 
>> drive uses zone recording; such complexity can be hidden inside the 
>> controller firmware.  But I don't know if that was actually done, either at 
>> that time or in later generations.
> 
> Good grief, it took DEC all that time?  CDC was doing it in the 1960s.
> Had to, because of the wide variety of RMS available.   I think that
> one of the early 2311 clone drives (854?) used 256-byte (8 bit byte)
> hard-sectored media, which isn't very friendly to systems with 60 bit
> words.   I recall that several sectors were used to create a logical
> 60-bit word addressable sector, with a substantial part of the last
> sector of a logical PRU left unused.

I didn't know that one.  The only drive I really know is the 844, an RP04 
lookalike, which does have friendly size sectors, laid out by the controller 
("BSC").

LBA addressing, in CDC?  Where is that?  On the 6000 series, I remember classic 
c/h/s addressing.  The OS would convert those to "logical track and sector" 
addresses, sure.  But that was a file system structure thing really.  PLATO 
ignored all that overhead and laid its own file system directly on top of the 
disks, with the file system block offset to c/h/s mapping done in the PP.  So 
yes, it necessarily knew the drive layout.

For that matter, with "logical tracks" the OS still had to know the layout; it 
just got buried into the logical to physical mapping system request code, in 
the CP monitor for extra inefficiency.

paul

Re: OT: Who? What? Was: Re: Origin of "partition" in storage devices

[Chuck Guzis via cctalk]

On 2/1/22 13:40, Paul Koning via cctalk wrote:
> 

> With MSCP, DEC switched to addressing disks by sector offset, as SCSI did 
> later, rather than by geometry (cylinder, track, sector) on devices like the 
> RK05 and RP06.  If the OS sees only an LBA, it doesn't matter whether the 
> drive uses zone recording; such complexity can be hidden inside the 
> controller firmware.  But I don't know if that was actually done, either at 
> that time or in later generations.

Good grief, it took DEC all that time?  CDC was doing it in the 1960s.
 Had to, because of the wide variety of RMS available.   I think that
one of the early 2311 clone drives (854?) used 256-byte (8 bit byte)
hard-sectored media, which isn't very friendly to systems with 60 bit
words.   I recall that several sectors were used to create a logical
60-bit word addressable sector, with a substantial part of the last
sector of a logical PRU left unused.

--Chuck

Re: OT: Who? What? Was: Re: Origin of "partition" in storage devices

[Grant Taylor via cctalk]

On 2/1/22 2:40 PM, Paul Koning via cctalk wrote:

Mass Storage Control Protocol...

Thank you Paul.

My brain was trying to expand to a company, and ending up at MASSCOMP 
before failing.




--
Grant. . . .
unix || die

Re: OT: Who? What? Was: Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 4:31 PM, Grant Taylor via cctalk  
> wrote:
> 
> On 2/1/22 11:23 AM, Paul Koning via cctalk wrote:
>> Did any DEC MSCP disks use it?
> 
> Please expand "MSCP".  My brain is failing to do so at the moment.

Mass Storage Control Protocol, the geometry-independent storage access scheme 
DEC created in the early 1980s.  Early implementations include the HSC50 (for 
VAXclusters) and the UDA50 (Unibus adapter), talking to disk drives such as the 
RA80.

With MSCP, DEC switched to addressing disks by sector offset, as SCSI did 
later, rather than by geometry (cylinder, track, sector) on devices like the 
RK05 and RP06.  If the OS sees only an LBA, it doesn't matter whether the drive 
uses zone recording; such complexity can be hidden inside the controller 
firmware.  But I don't know if that was actually done, either at that time or 
in later generations.

paul

OT: Who? What? Was: Re: Origin of "partition" in storage devices

[Grant Taylor via cctalk]

On 2/1/22 11:23 AM, Paul Koning via cctalk wrote:

Did any DEC MSCP disks use it?


Please expand "MSCP".  My brain is failing to do so at the moment.



--
Grant. . . .
unix || die

Re: Origin of "partition" in storage devices

[Fred Cisin via cctalk]

Covering more distance in the same time means increased speed to me!


On Tue, 1 Feb 2022, Jon Elson via cctalk wrote:
Clearly, on a disk, the outer tracks ARE moving faster, in terms of linear 
velocity.


If the data is written at a constant data transfer rate, and the motion of 
the disk is the same when reading as for writing, then the data transfer 
rate in unaffected.


With CAV, the physical width of the bits is larger on the outer tracks, 
where the linear velocity is higher.

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 2:42 PM, Grant Taylor via cctalk  
> wrote:
> 
> On 2/1/22 2:14 AM, Joshua Rice via cctalk wrote:
>> There's several advantages to doing it that way, including balancing wear on 
>> a disk (especially today, with SSDs), as a dedicated swap partition could 
>> put undue wear on certain areas of disk.
> 
> I thought avoiding this very problem was the purpose of the wear leveling 
> functions in SSD controllers.

Definitely.  But apparently wear from repeated writes is a thing on very high 
density modern HDDs, much to my surprise.  It's not as dramatic as flash memory 
but it apparently does exist.  For most purposes it probably isn't very 
important.  Especially not swap partitions: if you're swapping enough for this 
to matter you have bigger problems.  :-)

paul

Re: Origin of "partition" in storage devices

[Cameron Kaiser via cctalk]

>> There's several advantages to doing it that way, including balancing wear on
>> a disk (especially today, with SSDs), as a dedicated swap partition could put
>> undue wear on certain areas of disk.
> 
> I thought avoiding this very problem was the purpose of the wear leveling
> functions in SSD controllers.

Yeah, it's all block level now. The controller shouldn't care about the purpose
of an individual block.
-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- A/C was the worst thing that ever happened to Washington. -- Harry S Truman

Re: Origin of "partition" in storage devices

[Grant Taylor via cctalk]

On 2/1/22 2:14 AM, Joshua Rice via cctalk wrote:
There's several advantages to doing it that way, including balancing 
wear on a disk (especially today, with SSDs), as a dedicated swap 
partition could put undue wear on certain areas of disk.


I thought avoiding this very problem was the purpose of the wear 
leveling functions in SSD controllers.




--
Grant. . . .
unix || die

Re: Origin of "partition" in storage devices

[Fred Cisin via cctalk]

Many/most? early drives were CAV (Constant Angeular Velocity) with the 
same amount of data on each track.


Therefore, the data transfer rate, once on the right track, was the same.

BUT, the bits were physically closer to each other on the inner (higher 
numbered) tracks, and the error rate was sometimes noticeably higher on 
the inner tracks.  (and hence TG43 on 8"drives)  That was why most OS's 
would allocate space starting at the outside (lower numbered) tracks, and 
only use the innermost tracks when necessary.  With no errors, inner and 
outer tracks were the same speed. BUT, if you count RETRY's on a less than 
a perfect disk, then outer tracks had faster access than inner tracks.



In addition, track to track step times were conservative, often without 
knowing what step rate the drive could do, to allow plenty of time for 
completion and settling. In fact, one of the changes from PC-DOS 2.00 to 
PC-DOS 2.10 was to slow the step rate, because the Qumetrak 142 drives in 
the Convertible and PCJr were much slower.


Some floppy drives could do a "Recalibrate" (seek to track 0) much faster, 
and use a track 0 sensor to know when it had arrived.  Many OS's, when 
they encountered a "SEEK ERROR" (reading the track shows a different track 
number than desired), would RECALIBRATE and then step by step seek back to 
the desired track, rather than calculating how many tracks they were off. 
Because of that, access time to get to the desired track was sometimes 
faster for the outer (lower numbered) tracks, due to detours to track 0.


Since the DIRectory gets accessed more than any other location, access 
time to the DIRectory track is especially important.
Some OS's, including Microsoft Stand-Alone BASIC, COCO, etc. put the 
DIRectory at the seek center. So long as there were no "SEEK ERROR"s, that 
was faster, but when there WERE "SEEK ERROR"s, putting the DIRectory on 
track 0 (such as MS-DOS and Mac) was faster.

Re: Origin of "partition" in storage devices

[Fred Cisin via cctalk]

On Tue, 1 Feb 2022, Peter Corlett via cctalk wrote:

FAT's *file* size limitation is indeed due to a 32 bit field. The ISO 9660
standard offers an "interesting" solution to that, namely having multiple
directory entries for the same filename. So if you want to store files
larger than 4GiB on a CD-ROM, the filesystem won't hold you back.


Multiple DIRectory entries ("extents") for the same file was also how CP/M 
handled "large" files.


And, how Windoze stores "long filenames", although that's just using up 
DIRectory space for the filenames, with a pointer to the "real" entry.

Re: Origin of "partition" in storage devices

[Jon Elson via cctalk]

On 2/1/22 10:17, Nigel Johnson Ham via cctalk wrote:
Covering more distance in the same time means increased 
speed to me!


Clearly, on a disk, the outer tracks ARE moving faster, in 
terms of linear velocity.

Jon

Re: Origin of "partition" in storage devices

[Paul Berger via cctalk]

On 2022-02-01 14:09, Glen Slick via cctalk wrote:

On Tue, Feb 1, 2022 at 10:04 AM Paul Koning via cctalk
 wrote:

Slower on the outer tracks, I believe.  CDs work this way.

I suspect CLV was invented for CDs, in fact.

Which came first CLV CDs, or CLV LaserDiscs?


How about CLV diskettes as used in the Victor 9000 that changed 
rotational speed several times to obtain higher capacity on 5.25 
diskettes.  I wonder how long it took to settle after stepping over a 
speed change boundary.


Paul.

Re: Origin of "partition" in storage devices

[Chris Zach via cctalk]

Which came first CLV CDs, or CLV LaserDiscs?


Laserdiscs by far. Only the very first models played CAV only.

CAV is nice because you can freeze frame without a frame buffer.

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 1:03 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 2/1/22 09:16, Mike Katz via cctalk wrote:
>> In the rotating drive world there is constant linear velocity (CLV) and
>> constant angular velocity (CAV) drives.
>> 
>> On CLV drives the speed of rotation would vary based on the track
>> (slower in the inner tracks and faster on the outer tracks).  This meant
>> that the data rate and number of bits/track remained constant.
>> 
>> On CAV drives the rotational speed of the drive doesn't change, this
>> means that the data rate and number of bits/track changes depending on
>> the track.
> 
> I suspect that most recent ATA and SCSI drives employ "Zoned" recording.
> That is, the disk is divided up into several annular "zones", each with
> its own data rate.The rotational speed remains constant, however.

As far as I know zoned recording is universal at this point.  Don't know how 
far back it goes.  Did any DEC MSCP disks use it?

> This is not even recent.  The old Bryant 4000 disks used such a scheme
> and it was used on many old drives after that.

Those are the ones CDC sold as 6603.  Four zones, handled by the driver.  (Also 
12 bit parallel data rather than the usual serial data stream.)

paul

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 1:09 PM, Glen Slick via cctalk  
> wrote:
> 
> On Tue, Feb 1, 2022 at 10:04 AM Paul Koning via cctalk
>  wrote:
>> 
>>> Slower on the outer tracks, I believe.  CDs work this way.
>> 
>> I suspect CLV was invented for CDs, in fact.
> 
> Which came first CLV CDs, or CLV LaserDiscs?

I forgot about LaserDisc.  That's earlier, says Wikipedia.

paul

Re: Origin of "partition" in storage devices

[Glen Slick via cctalk]

On Tue, Feb 1, 2022 at 10:04 AM Paul Koning via cctalk
 wrote:
>
> > Slower on the outer tracks, I believe.  CDs work this way.
>
> I suspect CLV was invented for CDs, in fact.

Which came first CLV CDs, or CLV LaserDiscs?

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 12:21 PM, Paul Koning via cctalk  
> wrote:
> 
>> On Feb 1, 2022, at 12:16 PM, Mike Katz via cctalk  
>> wrote:
>> 
>> In the rotating drive world there is constant linear velocity (CLV) and 
>> constant angular velocity (CAV) drives.
>> 
>> On CLV drives the speed of rotation would vary based on the track (slower in 
>> the inner tracks and faster on the outer tracks).  This meant that the data 
>> rate and number of bits/track remained constant.
> 
> Slower on the outer tracks, I believe.  CDs work this way.

I suspect CLV was invented for CDs, in fact.  The reason is obvious: CDs 
contain uncompressed digital audio, i.e., constant bit rate.  If you want to 
avoid big buffers -- an expensive thing to have in 1980s consumer electronics 
-- the bits have to come off the media at essentially the desired payload data 
rate.  So you either use CAV with constant sector counts, which wastes a whole 
lot of capacity given that the ratio of inner to outer radius is quite large on 
a CD, or you go to CLV.  The variable rotation rate is easy enough to handle 
because CDs are accessed sequentially; the speed change on track switch is 
small because track switches are only by +1 (during play).

You can often hear the RPM changes clearly, if you're asking the CD player to 
do random access by skipping around the songs.

paul

Re: Origin of "partition" in storage devices

[Chuck Guzis via cctalk]

On 2/1/22 09:16, Mike Katz via cctalk wrote:
> In the rotating drive world there is constant linear velocity (CLV) and
> constant angular velocity (CAV) drives.
> 
> On CLV drives the speed of rotation would vary based on the track
> (slower in the inner tracks and faster on the outer tracks).  This meant
> that the data rate and number of bits/track remained constant.
> 
> On CAV drives the rotational speed of the drive doesn't change, this
> means that the data rate and number of bits/track changes depending on
> the track.

I suspect that most recent ATA and SCSI drives employ "Zoned" recording.
 That is, the disk is divided up into several annular "zones", each with
its own data rate.The rotational speed remains constant, however.

This is not even recent.  The old Bryant 4000 disks used such a scheme
and it was used on many old drives after that.

--Chuck

Re: Origin of "partition" in storage devices

[Mike Katz via cctalk]

In those cases the bits/inch changed to keep a constant data rate and 
constant number of bits and sectors per track.


On 2/1/2022 11:21 AM, Paul Koning wrote:



On Feb 1, 2022, at 12:16 PM, Mike Katz via cctalk  wrote:

In the rotating drive world there is constant linear velocity (CLV) and 
constant angular velocity (CAV) drives.

On CLV drives the speed of rotation would vary based on the track (slower in 
the inner tracks and faster on the outer tracks).  This meant that the data 
rate and number of bits/track remained constant.

Slower on the outer tracks, I believe.  CDs work this way.


On CAV drives the rotational speed of the drive doesn't change, this means that 
the data rate and number of bits/track changes depending on the track.

It means that only if the sector count changes.  That's true for modern drives and for 
the CDC 6603; it wasn't true for quite a while.  A lot of "classic" disk drives 
have constant sector counts.  So, for example, an RP06 is a CAV drive and its transfer 
rate is independent of cylinder number since the sector count per track is constant.

I think hard drives are CAV as a rule because changing the spin rate as part of 
a seek takes too long.

paul

Re: Origin of "partition" in storage devices

[Chuck Guzis via cctalk]

There's also hardware partitioning.   Back in the bad old days of the
5160 PC, some DTC controllers allowed for partitioning a drive (using
witch settings) into two smaller drives.   I don't recall the exact BIOS
revision (BXD05?) where this came into play, but I have the manual.

--Chuck

Re: Origin of "partition" in storage devices

[Jay Jaeger via cctalk]

Sent from my iPad

> On Feb 1, 2022, at 10:43, Jon Elson via cctalk  wrote:
> 
> On 2/1/22 00:38, Peter Corlett via cctalk wrote:
>> On Mon, Jan 31, 2022 at 07:51:28PM -0500, Paul Koning via cctalk wrote:
>> [...]
>>> Yes, RT-11 is a somewhat unusual file system in that it doesn't just
>>> support contiguous files -- it supports ONLY contiguous files. That makes
>>> for a very small and very fast file system.
> 
> Well, the IBM 360 CKD disks had all files contiguous, too.
> 
> Jon
> 

That is not accurate.  CKD files (and FBA files, for that matter) can have 
multiple *extents*.  An extent is contiguous by nature, but if a file has 
multiple extents it is not contiguous other than by coincidence.

Side note:  Intergraph made disk controllers for the PDP11 and Vaxen that 
required graphics files (IGDS) to be contiguous so that the on-board CPU could 
scan for graphic element characteristics (layer, type, etc.)

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 12:21 PM, Paul Koning via cctalk  
> wrote:
> 
> 
> 
>> On Feb 1, 2022, at 12:16 PM, Mike Katz via cctalk  
>> wrote:
>> 
>> In the rotating drive world there is constant linear velocity (CLV) and 
>> constant angular velocity (CAV) drives.
>> 
>> On CLV drives the speed of rotation would vary based on the track (slower in 
>> the inner tracks and faster on the outer tracks).  This meant that the data 
>> rate and number of bits/track remained constant.
> 
> Slower on the outer tracks, I believe.  CDs work this way.

More precisely:

CLV means slower rotation when positioned on the outer cylinders.  The outer 
cylinders have more sectors; the layout is such that the linear bit density is 
roughly constant, which in turn because of the constant linear velocity means 
constant data rate.

>> On CAV drives the rotational speed of the drive doesn't change, this means 
>> that the data rate and number of bits/track changes depending on the track.
> 
> It means that only if the sector count changes.  That's true for modern 
> drives and for the CDC 6603; it wasn't true for quite a while.  A lot of 
> "classic" disk drives have constant sector counts.  So, for example, an RP06 
> is a CAV drive and its transfer rate is independent of cylinder number since 
> the sector count per track is constant.
> 
> I think hard drives are CAV as a rule because changing the spin rate as part 
> of a seek takes too long.

Variable sector count is independent of CLV vs. CAV.  Modern drives have it, 
classic CAV drives mostly do not.  A CAV drive with fixed sector counts has 
fixed data rate; a CAV drive with more sectors on the outer tracks has higher 
transfer rate on those tracks.

paul

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 12:16 PM, Mike Katz via cctalk  
> wrote:
> 
> In the rotating drive world there is constant linear velocity (CLV) and 
> constant angular velocity (CAV) drives.
> 
> On CLV drives the speed of rotation would vary based on the track (slower in 
> the inner tracks and faster on the outer tracks).  This meant that the data 
> rate and number of bits/track remained constant.

Slower on the outer tracks, I believe.  CDs work this way.

> On CAV drives the rotational speed of the drive doesn't change, this means 
> that the data rate and number of bits/track changes depending on the track.

It means that only if the sector count changes.  That's true for modern drives 
and for the CDC 6603; it wasn't true for quite a while.  A lot of "classic" 
disk drives have constant sector counts.  So, for example, an RP06 is a CAV 
drive and its transfer rate is independent of cylinder number since the sector 
count per track is constant.

I think hard drives are CAV as a rule because changing the spin rate as part of 
a seek takes too long.

paul

Re: Origin of "partition" in storage devices

[Mike Katz via cctalk]

In the rotating drive world there is constant linear velocity (CLV) and 
constant angular velocity (CAV) drives.


On CLV drives the speed of rotation would vary based on the track 
(slower in the inner tracks and faster on the outer tracks).  This meant 
that the data rate and number of bits/track remained constant.


On CAV drives the rotational speed of the drive doesn't change, this 
means that the data rate and number of bits/track changes depending on 
the track.



On 2/1/2022 10:14 AM, Jon Elson via cctalk wrote:

On 2/1/22 04:02, Liam Proven via cctalk wrote:


One of our favourite small PC builders, Panrix, questioned this. They
reckoned that having the swap file on the outer, longer tracks of the
drive made it slower, due to slower access times and slower transfer
speeds. They were adamant.

HUH?  Yes, the outer tracks ARE longer, but the whole platter spins at 
the same angular velocity, so there can't be any speed difference!  
Did they think there is a whole bunch of magnetic tape inside the 
drive?  Wow!


Jon

Re: Origin of "partition" in storage devices

[Antonio Carlini via cctalk]

On 01/02/2022 16:17, Nigel Johnson Ham via cctalk wrote:

Covering more distance in the same time means increased speed to me!



Not if you stretch the bits, as older drives did. You are still covering 
more linear distance per unit time but the magnetic data is smeared out 
just enough to counteract this. This is the disk equivalent of the 
Lorentz contraction. :-)



So the relative speed of your head over the platter is faster but the 
observable effect (data transfer rate) is the same as it is on the inner 
tracks.



Antonio



--
Antonio Carlini
anto...@acarlini.com

Re: Origin of "partition" in storage devices

[Warner Losh via cctalk]

On Tue, Feb 1, 2022, 9:14 AM Jon Elson via cctalk 
wrote:

> On 2/1/22 04:02, Liam Proven via cctalk wrote:
> >
> > One of our favourite small PC builders, Panrix, questioned this. They
> > reckoned that having the swap file on the outer, longer tracks of the
> > drive made it slower, due to slower access times and slower transfer
> > speeds. They were adamant.
> >
> HUH?  Yes, the outer tracks ARE longer, but the whole
> platter spins at the same angular velocity, so there can't
> be any speed difference!  Did they think there is a whole
> bunch of magnetic tape inside the drive?  Wow!
>

Drive makers these days use variable bit rates to increase density of the
outer tracks. The lower LBAs these days are faster for sequential transfer
than the inner tracks by as much as 20%.

Warner

Re: Origin of "partition" in storage devices

[Liam Proven via cctalk]

On Tue, 1 Feb 2022 at 14:50, Maciej W. Rozycki  wrote:
>
>  With contemporary ATA hard disks (and also SCSI disks) obviously the
> opposite was the case, due to the ZBR sector mapping scheme.

Zone bit recording?

> The outer
> cylinders had the fastest transfer speeds.

Ah, OK.

Also bearing in mind Paul K's similar point:

On Tue, 1 Feb 2022 at 15:20, Paul Koning  wrote:
[...]
> And very obviously wrong -- elementary geometry.
[...]
> The bits are physically longer, of course.  That's why later drives put more 
> sectors per track as you move outward, and that means that the transfer rate 
> on outer tracks is *higher* than for inner tracks.  And some storage systems 
> indeed use that knowledge.

So, taking both these in mind and checking my references, I think I
had it backwards.

According to:
https://www.file-recovery.com/recovery-hard-disk-drive-basics.htm#:~:text=Tracks%20and%20Cylinders=Track%20numbers%20start%20at%200,track%20would%20typically%20be%201023.

Track 0 is the _outermost_ track.

So the upshot is the same: Panrix were concerned that putting a swap
partition on the highest-numbered tracks would mean it was on the
slowest part of the disk.

But I had it backwards -- that means, at the centre of the platters:
inner tracks, not outer.

Anyway, I took a virgin machine of theirs, defragged it, benchmarked
it, created a swap partition at the end of the drive, moved the swap
there, defragged both drives, and benchmarked it again.

No consistent measurable difference to 2 decimal places.

This was a real-world benchmark using MS Office, Photoshop and other
tools. A full run took 20min or so on a fast PC for 1996.

What I was able to demonstrate was that location on the hard disk of
the swap file made no measurable impact. They were very surprised by
this.

My personal takeaway from running that magazine's labs for a couple of
years is that a lot of PC performance lore had about as much validity
as astrology, homeopathy or the Myers-Briggs test.

I.e. none at all.




-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

Re: Origin of "partition" in storage devices

[Nigel Johnson Ham via cctalk]

Covering more distance in the same time means increased speed to me!

Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype:  tilbury2591nw.john...@ieee.org



On 2022-02-01 11:14, Jon Elson via cctalk wrote:

On 2/1/22 04:02, Liam Proven via cctalk wrote:


One of our favourite small PC builders, Panrix, questioned this. They
reckoned that having the swap file on the outer, longer tracks of the
drive made it slower, due to slower access times and slower transfer
speeds. They were adamant.

HUH?  Yes, the outer tracks ARE longer, but the whole platter spins at 
the same angular velocity, so there can't be any speed difference!  
Did they think there is a whole bunch of magnetic tape inside the 
drive?  Wow!


Jon

Re: Origin of "partition" in storage devices

[Jon Elson via cctalk]

On 2/1/22 04:02, Liam Proven via cctalk wrote:


One of our favourite small PC builders, Panrix, questioned this. They
reckoned that having the swap file on the outer, longer tracks of the
drive made it slower, due to slower access times and slower transfer
speeds. They were adamant.

HUH?  Yes, the outer tracks ARE longer, but the whole 
platter spins at the same angular velocity, so there can't 
be any speed difference!  Did they think there is a whole 
bunch of magnetic tape inside the drive?  Wow!


Jon

Re: Origin of "partition" in storage devices

[Jon Elson via cctalk]

On 2/1/22 00:38, Peter Corlett via cctalk wrote:

On Mon, Jan 31, 2022 at 07:51:28PM -0500, Paul Koning via cctalk wrote:
[...]

Yes, RT-11 is a somewhat unusual file system in that it doesn't just
support contiguous files -- it supports ONLY contiguous files. That makes
for a very small and very fast file system.


Well, the IBM 360 CKD disks had all files contiguous, too.

Jon

Re: Origin of "partition" in storage devices

[Warner Losh via cctalk]

On Tue, Feb 1, 2022 at 1:22 AM Huw Davies via cctalk 
wrote:

>
>
> > On 1 Feb 2022, at 09:42, cctalk@classiccmp.org wrote:
> >
> > A somewhat broader search found the 1984 RT-11 System Release Notes with
> the following:
> >
> >
> >
> > 1.4.2.4 Logical Disk Subsetting Handler (LD) - The logical disk
> subsetting handler lets you define logical disks, which are subsets of
> physical disks. You define logical disks by assigning a logical disk unit
> number to a file on a physical disk. You can then use the logical disk as
> though it were a physical disk.
> >
> > AA-5286F-TC-T1_RT-11_System_Release_Notes_Jul84.pdf (bitsavers.org) <
> http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.1_Jul84/AA-5286F-TC-T1_RT-11_System_Release_Notes_Jul84.pdf>
> p15/102
> >
> >
> >
> > Suggests DEC had not yet adopted the term “partition” for a segment of a
> disk
>
> From
> http://bitsavers.org/pdf/dec/pdp11/ultrix-11/2.0/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf
> <
> http://bitsavers.org/pdf/dec/pdp11/ultrix-11/2.0/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf>
> it seems that at least one part of Digital used partitions as we now know
> it in September 1984. I wonder if AT Unix Seventh edition also called
> them partitions?
>

Unix has called these "pseudo-disks" in Unix 4th edition through the 7th
edition, at least in their driver man pages.

The 6th and 7th edition setup guides, however, have this in them:

The big disk drivers (rp.c and hp.c)
have partition tables in them which you
may want to experiment with.

which dates from March, 1975 and seems to be in /usr/start/start in the
distributions.

Warner

Re: Origin of "partition" in storage devices

[Kenneth Gober via cctalk]

On Mon, Jan 31, 2022 at 4:43 PM Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Paul Koning
>
> > When did Unix first get partitions?
>
> 'Partitions' the mechanism, or partitions the term for the mechanism?
>
> The former appeared about V5:
>
>   https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/dmr/rp.c
>
> when an RP03 was added; pre-V7, UNIX filesystems were limited to 2^16
> blocks,
> so the 406*10*20 blocks of an RP03 had to be split up into partitions
> (called
> 'sections' or 'pseudo-disks' in the documentation) to make all of it
> useable.
>
> The latter? No idea...
>

In the Unix V5 rp(4) man page the term "sections" is used.  See page 222 of
https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf

In "Setting Up Unix - Sixth Edition" the term "partitions" is used,
although the rp(4) man page still used "sections" in V6 and V7.  See
https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/start/start

-ken

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Feb 1, 2022, at 5:02 AM, Liam Proven via cctalk  
> wrote:
> 
> ...
> I suggested making a D: drive and putting the swap file on it -- you
> saved space and reduced fragmentation.
> 
> One of our favourite small PC builders, Panrix, questioned this. They
> reckoned that having the swap file on the outer, longer tracks of the
> drive made it slower, due to slower access times and slower transfer
> speeds. They were adamant.

And very obviously wrong -- elementary geometry. 

It is true that the outer tracks are physically longer.  But that doesn't mean 
transfer rates are slower.  Given the older formatting where the count of 
sectors per track is constant, so is the transfer rate -- the same number of 
sectors pass the head per revolution, i.e., in constant time, no matter what 
track you're on.

The bits are physically longer, of course.  That's why later drives put more 
sectors per track as you move outward, and that means that the transfer rate on 
outer tracks is *higher* than for inner tracks.  And some storage systems 
indeed use that knowledge.

Incidentally, while constant sector count was the norm for a long time, it 
wasn't universal; the CDC 6603, in 1964, had "zones" with the sector count 
changing between zones.  Outer zones had more sectors per track.  Unlike modern 
drives, the OS driver had to handle that.

paul

Re: Origin of "partition" in storage devices

[Maciej W. Rozycki via cctalk]

On Tue, 1 Feb 2022, Liam Proven via cctalk wrote:

> One of our favourite small PC builders, Panrix, questioned this. They
> reckoned that having the swap file on the outer, longer tracks of the
> drive made it slower, due to slower access times and slower transfer
> speeds. They were adamant.

 With contemporary ATA hard disks (and also SCSI disks) obviously the 
opposite was the case, due to the ZBR sector mapping scheme.  The outer 
cylinders had the fastest transfer speeds.  Verified many times with 
actual benchmarking of partitions placed at different parts of various 
disks (only with Linux however).

 I only ever came across a single very old WDC ATA disk that had a fixed 
sector count per track/cylinder like a floppy (and also a stepper rather 
than linear motor for the head assembly, which obviously affected seek 
characteristics) and consequently whose transfer speed was the same all 
across the surface.

 FWIW,

  Maciej

Re: Origin of "partition" in storage devices

[Liam Proven via cctalk]

On Tue, 1 Feb 2022 at 10:14, Joshua Rice via cctalk
 wrote:

> Of course, doing it that way has many disadvantages, not least the
> fragmentation issue (which was the root cause of much periodic slowdown
> on Windows machines in the mid 00's), but also the overheads involved
> with transferring rather scattered and unorganised RAM contents into
> nice, neat blocks understood by the filesystem. Though i have no numbers
> to back up my claims, i'm sure the overheads involved in translating RAM
> contents to a file was much more significant than just dumping the RAM
> contents into a SWAP partition.

Yeah... there were folk beliefs about how positioning on the disk made
a big difference, too.

When PartitionMagic came out, it caused me some fun. When I joined _PC
Pro_ magazine (at Issue 8) we had a copy of v1 in the cupboard. Its
native OS was OS/2 and nobody cared, I'm afraid. I read what it
claimed and didn't believe it so I didn't try it.

Then v2 arrived. It ran on DOS. Repartitioning a hard disk when it was
full of data? Preposterous! Impossible!

So I tried it. It worked. I wrote a rave review.

It prompted a reader letter.

"I think I've spotted your April Fool's piece. A DOS program that
looks exactly like a Windows 95 app? Which can repartition a hard disk
full of data? Written by someone whose name is an anagram of 'APRIL
VENOM'? Do I win anything?"
He won a phonecall from me, but he did teach me an anagram of my name
I never knew.

It led me to run a tip in the mag...

At the time, a 1.2 GB hard disk was the most common size (and a
Quantum Fireball the fastest model for the money). Format that as a
single FAT16 partition and you got super-inefficient 16 kB clusters.
(And in 1995 or early 1996, FAT16 was all you got.)

With PartitionMagic, you could take 200 MB off the end, make it into a
2nd partition, and *still fit more onto the C: drive* because of far
more efficient 8 kB clusters. If you didn't have PQMagic you could
partition the disk that way before installing.

The only key thing was that C: was less than 1 GB. 0.99 GB was fine.

I suggested making a D: drive and putting the swap file on it -- you
saved space and reduced fragmentation.

One of our favourite small PC builders, Panrix, questioned this. They
reckoned that having the swap file on the outer, longer tracks of the
drive made it slower, due to slower access times and slower transfer
speeds. They were adamant.

So I got them to bring in a new, virgin PC with Windows 95A, I
benchmarked it with a single big, inefficient C: partition, then I
repartitioned it, put the swapfile on the new D: drive, and
benchmarked it again. It was the same to 2 decimal places, and the C
drive had about 250MB more free space.

Panrix apologised and I gained another geek cred point. :-)

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

Re: Origin of "partition" in storage devices

[Joshua Rice via cctalk]

This reminds me of the swapping/paging area in Windows 95/98 (maybe 
other
versions too), which was kept in a file, and therefore might be 
scattered all
over the physical disk. (Norton disk optimizer would coalesce the 
swap/paging

area to a contiguous area of the disk.)
Noel


Windows still uses a pagefile, even today, on NT systems.

There's several advantages to doing it that way, including balancing 
wear on a disk (especially today, with SSDs), as a dedicated swap 
partition could put undue wear on certain areas of disk. It's also much 
easier to dynamically allocate more (or less) swap space as is needed, 
which was very important in the days when RAM was expensive and very 
limited in quantity.


Of course, doing it that way has many disadvantages, not least the 
fragmentation issue (which was the root cause of much periodic slowdown 
on Windows machines in the mid 00's), but also the overheads involved 
with transferring rather scattered and unorganised RAM contents into 
nice, neat blocks understood by the filesystem. Though i have no numbers 
to back up my claims, i'm sure the overheads involved in translating RAM 
contents to a file was much more significant than just dumping the RAM 
contents into a SWAP partition.


Josh Rice

Re: Origin of "partition" in storage devices

[Huw Davies via cctalk]

> On 1 Feb 2022, at 09:42, cctalk@classiccmp.org wrote:
> 
> A somewhat broader search found the 1984 RT-11 System Release Notes with the 
> following:
> 
> 
> 
> 1.4.2.4 Logical Disk Subsetting Handler (LD) - The logical disk subsetting 
> handler lets you define logical disks, which are subsets of physical disks. 
> You define logical disks by assigning a logical disk unit number to a file on 
> a physical disk. You can then use the logical disk as though it were a 
> physical disk.
> 
> AA-5286F-TC-T1_RT-11_System_Release_Notes_Jul84.pdf (bitsavers.org) 
> 
>   p15/102
> 
> 
> 
> Suggests DEC had not yet adopted the term “partition” for a segment of a disk

From 
http://bitsavers.org/pdf/dec/pdp11/ultrix-11/2.0/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf
 

 it seems that at least one part of Digital used partitions as we now know it 
in September 1984. I wonder if AT Unix Seventh edition also called them 
partitions?

Huw

Re: Origin of "partition" in storage devices

[Peter Corlett via cctalk]

On Mon, Jan 31, 2022 at 07:51:28PM -0500, Paul Koning via cctalk wrote:
[...]
> Yes, RT-11 is a somewhat unusual file system in that it doesn't just
> support contiguous files -- it supports ONLY contiguous files. That makes
> for a very small and very fast file system.

> The only other example I know of that does this is the PLATO file system.

The first such one I encountered was Acorn's DFS. "Very small" is relative:
the filesystem came on an 16kiB ROM and stole 2,816 precious bytes of RAM
for its workspace. When you already only had 28,160 bytes free after the OS
had taken its fill, that's quite an extra imposition.

Other filesystems like this are anything which is expected to be generated
from a master image and written out linearly to mostly read-only storage,
such as ISO 9660, UDF, embedded systems, "booter" games and demos, etc.

Re: Origin of "partition" in storage devices

[Peter Corlett via cctalk]

On Mon, Jan 31, 2022 at 02:21:19PM -0800, Fred Cisin via cctalk wrote:
[...]
> That limit lasted until MS-DOS 3.31 / PC-DOS 4.00 After that, the limit
> was bumped up to 2GB. (Probably would have been 4GB if they had used an
> UNSIGNED 32 bit number, and given up the option of having negative file
> and drive sizes)

Fun factoid: that 2GiB limit on *filesystem* size is actually due to the use
of an signed *eight* bit field, namely the number of sectors in a cluster.
This limits clusters to 64 sectors, or 32kiB. FAT16 supports a shade under
2**16 clusters, resulting in that 2GiB limit.

FAT's *file* size limitation is indeed due to a 32 bit field. The ISO 9660
standard offers an "interesting" solution to that, namely having multiple
directory entries for the same filename. So if you want to store files
larger than 4GiB on a CD-ROM, the filesystem won't hold you back.

Re: Origin of "partition" in storage devices

[Maciej W. Rozycki via cctalk]

On Mon, 31 Jan 2022, Fred Cisin via cctalk wrote:

> File sizes were stored as the last 4 bytes of each DIRectory entry, with a
> signed 32 bit number. So, a file could be from
> -2,147,483,648 to 2,147,483,647
> Unfortunately, they never successfully finished the implementation, so copying
> a negative size file to the drive did not increase the free space.  Since they
> didn't make THAT work, perhaps they should have used an UNSIGNED 32 bit
> number, to permit files up to 4,294,967,295

 Consider the file seek operation however: with the file size limited to 
the 31-bit positive range of the signed 32-bit data type you can move the 
file offset backwards and forwards through the entire range with a single 
operation using the same data type.  It would not be possible if the data 
type was unsigned and all the 32 bits used for the file size.

  Maciej

Re: Origin of "partition" in storage devices

[ben via cctalk]

On 2022-01-31 6:19 p.m., Bill Gunshannon via cctalk wrote:

On 1/31/22 20:13, Fred Cisin via cctalk wrote:

On Mon, 31 Jan 2022, Paul Koning via cctalk wrote:
Yes, RT-11 is a somewhat unusual file system in that it doesn't just 
support contiguous files -- it supports ONLY contiguous files.  That 
makes for a very small and very fast file system.


The only other example I know of that does this is the PLATO file 
system.


The UCSD P-System had contiguous files.  If small files had been 
deleted, so that space was fragmented, you had to run a "CRUNCH" 
program to defragment it.   Directory entries had the starting 
location and length.


That was a minor inconvenience.  The bigger problem was that on a
"CRUNCHed" disk you could only open one file for writing. Attempt to
open a second returns an error.

bill


How are text files handled the above systems?
The editor writes to a temp file, then deletes
the old file, and renames the temp file?
Ben.

Re: Origin of "partition" in storage devices

[Bill Gunshannon via cctalk]

On 1/31/22 20:13, Fred Cisin via cctalk wrote:

On Mon, 31 Jan 2022, Paul Koning via cctalk wrote:
Yes, RT-11 is a somewhat unusual file system in that it doesn't just 
support contiguous files -- it supports ONLY contiguous files.  That 
makes for a very small and very fast file system.


The only other example I know of that does this is the PLATO file system.


The UCSD P-System had contiguous files.  If small files had been 
deleted, so that space was fragmented, you had to run a "CRUNCH" program 
to defragment it.   Directory entries had the starting location and length.


That was a minor inconvenience.  The bigger problem was that on a
"CRUNCHed" disk you could only open one file for writing. Attempt to
open a second returns an error.

bill

Re: Origin of "partition" in storage devices

[Fred Cisin via cctalk]

On Mon, 31 Jan 2022, Paul Koning via cctalk wrote:
Yes, RT-11 is a somewhat unusual file system in that it doesn't just 
support contiguous files -- it supports ONLY contiguous files.  That 
makes for a very small and very fast file system.


The only other example I know of that does this is the PLATO file system.


The UCSD P-System had contiguous files.  If small files had been deleted, 
so that space was fragmented, you had to run a "CRUNCH" program to 
defragment it.   Directory entries had the starting location and length.






As for partition vs. file, the two differences I see are: (1) layering: the 
partition is below the file system.  (2) partitions are originally entirely 
static (set at creation and never changed) and even later on changed only 
rarely and typically with substantial technical difficulty.

paul



--
Fred Cisin  ci...@xenosoft.com
XenoSofthttp://www.xenosoft.com
2245 Carquinez Avenue   (510) 234-3397
ElCerrito, CA 94530

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Jan 31, 2022, at 7:35 PM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Tom Gardner
> 
>> You define logical disks by assigning a logical disk unit number to a
>> file on a physical disk. You can then use the logical disk as though it
>> were a physical disk.
> 
> To me, 'partition' implies a contiguous are of the disk; "a file" to me
> implies that it might not be contiguous? Or are files contiguous in the RT-11
> filesystem? (I know there were filesystems which supported contiguous files.)

Yes, RT-11 is a somewhat unusual file system in that it doesn't just support 
contiguous files -- it supports ONLY contiguous files.  That makes for a very 
small and very fast file system.

The only other example I know of that does this is the PLATO file system.

As for partition vs. file, the two differences I see are: (1) layering: the 
partition is below the file system.  (2) partitions are originally entirely 
static (set at creation and never changed) and even later on changed only 
rarely and typically with substantial technical difficulty.

paul

Re: Origin of "partition" in storage devices

[Noel Chiappa via cctalk]

> From: Tom Gardner

>  You define logical disks by assigning a logical disk unit number to a
>  file on a physical disk. You can then use the logical disk as though it
>  were a physical disk.

To me, 'partition' implies a contiguous are of the disk; "a file" to me
implies that it might not be contiguous? Or are files contiguous in the RT-11
filesystem? (I know there were filesystems which supported contiguous files.)

This reminds me of the swapping/paging area in Windows 95/98 (maybe other
versions too), which was kept in a file, and therefore might be scattered all
over the physical disk. (Norton disk optimizer would coalesce the swap/paging
area to a contiguous area of the disk.)

Noel

Re: Origin of "partition" in storage devices

[Warner Losh via cctalk]

On Mon, Jan 31, 2022, 2:43 PM Noel Chiappa via cctalk 
wrote:

> > From: Paul Koning
>
> > When did Unix first get partitions?
>
> 'Partitions' the mechanism, or partitions the term for the mechanism?
>
> The former appeared about V5:
>
>   https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/dmr/rp.c
>
> when an RP03 was added; pre-V7, UNIX filesystems were limited to 2^16
> blocks,
> so the 406*10*20 blocks of an RP03 had to be split up into partitions
> (called
> 'sections' or 'pseudo-disks' in the documentation) to make all of it
> useable.
>
> The latter? No idea...
>

SunOS 1.0 had on disk tables that described the partitions in 1982. These
were dynamic per disk as opposed to the hardwired in the os drivers that V5
and later had. I've not had luck with finding people to recall where this
feature came from...

Partitions may have appeared in DOS/Windows for much the same reason; with
> 32
> KB clusters, FAT16 filesystems were limited to 2GB. I distinctly recall
> having to use partitions when I bought a 13GB hard drive for my Windows 95
> machine (FAT32 only came in with Windows 95 OSR2).
>

There were similar tables on DEC Rainbow disks which predated the MS DOS
port to the platform and was a different format. This was also 1981 or
1982. 3rd party disks had their own tables. I've not done the deep dive to
date it more specifically. Other CP/M raw disks from this era have similar
tables on them, but I have only what I've puzzled out, no docs.

Warner

>

Re: Origin of "partition" in storage devices

[Paul Berger via cctalk]

On 2022-01-31 18:21, Fred Cisin via cctalk wrote:

On Mon, 31 Jan 2022, Noel Chiappa via cctalk wrote:
Partitions may have appeared in DOS/Windows for much the same reason; 
with 32

KB clusters, FAT16 filesystems were limited to 2GB. I distinctly recall
having to use partitions when I bought a 13GB hard drive for my 
Windows 95

machine (FAT32 only came in with Windows 95 OSR2).


PC-DOS/MS-DOS early partitioning

When PC-DOS/MS-DOS started to support hard drives (XT/5160, March 
8,1983), with PC/MS-DOS 2.00, the limit was 32MB.  NOT 2GB.
That limit called for breaking up drives as small as 40MB into 
multiple partitions.
That limit lasted until MS-DOS 3.31 / PC-DOS 4.00  After that, the 
limit was bumped up to 2GB.  (Probably would have been 4GB if they had 
used an UNSIGNED 32 bit number, and given up the option of having 
negative file and drive sizes)


The XT/5160 shipped with a 10MB drive, but some people even split that 
up. ("we're going to share the drive between all of us, so there will 
be a partition for DOS and programs, and each person will get a 
personal partition for your data."


The XT/5160 used a rebranded Xebec hard disk controller, that included 
support for 2 drives, of 5?, 10, 16, and 26MB.  It was set for 10MB, 
but the other sizes could be accessed by adding jumpers to solder pads 
on the board.  Other sizes could be done with software kludges.


FDISK.COM, for partitioning, was included in PC-DOS 2.00 .

The 5160 shipped with the hard disk already formatted. However low 
level format, to redo it, or for a third party drive, required 
"Advanced Diagnostics", or third party solutions.
"Advanced Diagnostics" was part of the "Hardware Maintenance And 
Service" and was on a 160K floppy AND on a cassette! (for machines 
without floppy)
The regular "Diagnostics" that shipped with the machine (both 5150 and 
5160) did NOT have hard disk low level format.


Third party controllers usually came with a low-level format utility, 
or provision in the hard disk controller's ROM at C800h


--
Grumpy Ol' Fred ci...@xenosoft.com


The other thing you could do is alter the hard disk bios to support the 
disk you wanted to use, many years ago I did that for a gentleman that 
had a few 42GB disks, and he gave me one of the drives for my efforts.  
I also recall patching AT BIOS to support drive that didn't match the 
geometry of drives in the drive table.


Paul.

Re: Origin of "partition" in storage devices

[Fred Cisin via cctalk]

On Mon, 31 Jan 2022, Grant Taylor via cctalk wrote:
I think the same type of problem happened with the really old FAT-12 to 
FAT-16 conversion.

Wasn't FAT-12 limited to something near 31 MB?



On Mon, 31 Jan 2022, Fred Cisin via cctalk wrote:

32 MebiBytes - 1


On Mon, 31 Jan 2022, geneb wrote:
*chases Fred out of the house with a broom, screaming incoherently about SI 
units*


Sorry that I was in the house with a broom, screaming incoherently about 
SI units.


I think that the correct number is 33,554,432 bytes

File sizes were stored as the last 4 bytes of each DIRectory entry, with a 
signed 32 bit number. So, a file could be from

-2,147,483,648 to 2,147,483,647
Unfortunately, they never successfully finished the implementation, 
so copying a negative size file to the drive did not increase the free 
space.  Since they didn't make THAT work, perhaps they should have used an 
UNSIGNED 32 bit number, to permit files up to 4,294,967,295


The 5160/XT original drive was 306 cylinders, with 4 heads, and 17 sectors 
per track for 10,653,696

for 10.653696  "MegaBytes" 1,000,000 10^6
or 10.404  Marketing "MegaBytes" 1,024,00010^3 * 2^10
or 10.16015625 MebiBytes  2^20

Seagate, and a few others, were smart enough to call that 10MB, so that 
people forgave them a few bad tracks, and even bragged how great the drive 
was because it was even more than the ad had called it!


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: Origin of "partition" in storage devices

[Chuck Guzis via cctalk]

Note also, that tapes can be partitioned per ANSI T10.

---Chuck

Re: Origin of "partition" in storage devices

[geneb via cctalk]

On Mon, 31 Jan 2022, Fred Cisin via cctalk wrote:


On Mon, 31 Jan 2022, Grant Taylor via cctalk wrote:
I think the same type of problem happened with the really old FAT-12 to 
FAT-16 conversion.

Wasn't FAT-12 limited to something near 31 MB?


32 MebiBytes - 1



*chases Fred out of the house with a broom, screaming incoherently about 
SI units*


g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

Re: Origin of "partition" in storage devices

[Fred Cisin via cctalk]

On Mon, 31 Jan 2022, Grant Taylor via cctalk wrote:
I think the same type of problem happened with the really old FAT-12 to 
FAT-16 conversion.

Wasn't FAT-12 limited to something near 31 MB?


32 MebiBytes - 1

Re: Origin of "partition" in storage devices

[Tom Gardner via cctalk]

A somewhat broader search found the 1984 RT-11 System Release Notes with the 
following:

 

1.4.2.4 Logical Disk Subsetting Handler (LD) - The logical disk subsetting 
handler lets you define logical disks, which are subsets of physical disks. You 
define logical disks by assigning a logical disk unit number to a file on a 
physical disk. You can then use the logical disk as though it were a physical 
disk.

AA-5286F-TC-T1_RT-11_System_Release_Notes_Jul84.pdf (bitsavers.org) 
<http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.1_Jul84/AA-5286F-TC-T1_RT-11_System_Release_Notes_Jul84.pdf>
  p15/102

 

Suggests DEC had not yet adopted the term “partition” for a segment of a disk

 

Tom

 

-Original Message-
From: Tom Gardner [mailto:tom94...@comcast.net] 



FWIW a Google search:  "partition 
site:http://www.bitsavers.org/pdf/dec/pdp11/rt11; returns no relevant hits 
prior to 1983

 

I suspect that ESDI and MFM controllers emulating RL/RK disks are also later 
than 1983

 

Tom

 

-Original Message-

From: Zane Healy [ <mailto:heal...@avanthar.com> mailto:heal...@avanthar.com] 

Sent: Monday, January 31, 2022 12:40 PM

To: Paul Koning; General Discussion: On-Topic and Off-Topic Posts

Cc:  <mailto:t.gard...@computer.org> t.gard...@computer.org; Tom Gardner

Subject: Re: Origin of "partition" in storage devices

 

On Jan 31, 2022, at 11:28 AM, Paul Koning via cctalk < 
<mailto:cctalk@classiccmp.org> cctalk@classiccmp.org> wrote:

> 

> Both of these are memory partitions.   The only OS I can think of predating 
> the ones you mentioned is RT-11, the later versions (V2 did not have them).  
> When did Unix first get partitions?

> 

> paul

 

Partitions are pretty important in RT-11 v5.x, after all, there is the 
partition size limit, so you have to have multiple partitions for almost any 
HD, except very small ones.

 

Let�s not forget hardware enforced partitioning, the WEQSD/04 ESDI controller 
comes to mind.  It see�s a single large ESDI HD as a single disk, but you can 
partition it on the controller, and the OS sees each partition as a separate 
physical disk.  I seem to remember some MFM controllers that made the MFM drive 
appear to be RL01/RL02 or RK05 packs.

 

Zane

 

 

Re: Origin of "partition" in storage devices

[Grant Taylor via cctalk]

On 1/31/22 2:43 PM, Noel Chiappa via cctalk wrote:
Partitions may have appeared in DOS/Windows for much the same reason; 
with 32 KB clusters, FAT16 filesystems were limited to 2GB.


I think the same type of problem happened with the really old FAT-12 to 
FAT-16 conversion.


Wasn't FAT-12 limited to something near 31 MB?



--
Grant. . . .
unix || die

Re: Origin of "partition" in storage devices

[Fred Cisin via cctalk]

On Mon, 31 Jan 2022, Noel Chiappa via cctalk wrote:

Partitions may have appeared in DOS/Windows for much the same reason; with 32
KB clusters, FAT16 filesystems were limited to 2GB. I distinctly recall
having to use partitions when I bought a 13GB hard drive for my Windows 95
machine (FAT32 only came in with Windows 95 OSR2).


PC-DOS/MS-DOS early partitioning

When PC-DOS/MS-DOS started to support hard drives (XT/5160, March 8,1983), 
with PC/MS-DOS 2.00, the limit was 32MB.  NOT 2GB.
That limit called for breaking up drives as small as 40MB into multiple 
partitions.
That limit lasted until MS-DOS 3.31 / PC-DOS 4.00  After that, the limit 
was bumped up to 2GB.  (Probably would have been 4GB if they had used an 
UNSIGNED 32 bit number, and given up the option of having negative file 
and drive sizes)


The XT/5160 shipped with a 10MB drive, but some people even split that up. 
("we're going to share the drive between all of us, so there will be a 
partition for DOS and programs, and each person will get a personal 
partition for your data."


The XT/5160 used a rebranded Xebec hard disk controller, that included 
support for 2 drives, of 5?, 10, 16, and 26MB.  It was set for 
10MB, but the other sizes could be accessed by adding jumpers to solder 
pads on the board.  Other sizes could be done with software kludges.


FDISK.COM, for partitioning, was included in PC-DOS 2.00 .

The 5160 shipped with the hard disk already formatted. 
However low level format, to redo it, or for a third party drive, required 
"Advanced Diagnostics", or third party solutions.
"Advanced Diagnostics" was part of the "Hardware Maintenance And 
Service" and was on a 160K floppy AND on a cassette! (for machines without 
floppy)
The regular "Diagnostics" that shipped with the machine (both 5150 and 
5160) did NOT have hard disk low level format.


Third party controllers usually came with a low-level format utility, or 
provision in the hard disk controller's ROM at C800h


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: Origin of "partition" in storage devices

[Noel Chiappa via cctalk]

> From: Paul Koning

> When did Unix first get partitions?

'Partitions' the mechanism, or partitions the term for the mechanism?

The former appeared about V5:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/dmr/rp.c

when an RP03 was added; pre-V7, UNIX filesystems were limited to 2^16 blocks,
so the 406*10*20 blocks of an RP03 had to be split up into partitions (called
'sections' or 'pseudo-disks' in the documentation) to make all of it useable.

The latter? No idea...

Partitions may have appeared in DOS/Windows for much the same reason; with 32
KB clusters, FAT16 filesystems were limited to 2GB. I distinctly recall
having to use partitions when I bought a 13GB hard drive for my Windows 95
machine (FAT32 only came in with Windows 95 OSR2).

Noel

RE: Origin of "partition" in storage devices

[Tom Gardner via cctalk]

FWIW a Google search:  "partition 
site:http://www.bitsavers.org/pdf/dec/pdp11/rt11; returns no relevant hits 
prior to 1983

I suspect that ESDI and MFM controllers emulating RL/RK disks are also later 
than 1983

Tom

-Original Message-
From: Zane Healy [mailto:heal...@avanthar.com] 
Sent: Monday, January 31, 2022 12:40 PM
To: Paul Koning; General Discussion: On-Topic and Off-Topic Posts
Cc: t.gard...@computer.org; Tom Gardner
Subject: Re: Origin of "partition" in storage devices

On Jan 31, 2022, at 11:28 AM, Paul Koning via cctalk  
wrote:
> 
> Both of these are memory partitions.   The only OS I can think of predating 
> the ones you mentioned is RT-11, the later versions (V2 did not have them).  
> When did Unix first get partitions?
> 
>   paul

Partitions are pretty important in RT-11 v5.x, after all, there is the 
partition size limit, so you have to have multiple partitions for almost any 
HD, except very small ones.

Let�s not forget hardware enforced partitioning, the WEQSD/04 ESDI controller 
comes to mind.  It see�s a single large ESDI HD as a single disk, but you can 
partition it on the controller, and the OS sees each partition as a separate 
physical disk.  I seem to remember some MFM controllers that made the MFM drive 
appear to be RL01/RL02 or RK05 packs.

Zane

Re: Origin of "partition" in storage devices

[Mike Katz via cctalk]

The RK02/RK03 (Diablo predecessor to the DEC RK05) were introduced in 
1972 so partitioning goes back that far at least.


My guess is it goes back even further.

On 1/31/2022 7:41 PM, Bill Degnan via cctalk wrote:

OS/8 partitioned RK02 disk packs.

On Mon, Jan 31, 2022 at 2:38 PM Warner Losh via cctalk <
cctalk@classiccmp.org> wrote:


On Mon, Jan 31, 2022 at 12:01 PM Tom Gardner via cctalk <
cctalk@classiccmp.org> wrote:


There is a discussion of the origin of the term "partition" in storage
devices such as HDDs at:



https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22p

artition%22_originate
<

https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22partition%22_originate

?

It seems clear it was used in memory well before HDDs but when it got
started there is unclear.
* IBM PC DOS v2 was an early user in 1983 with FDISK and its first PC
support of HDDs
* UNIX, Apple OS's and IBM mainframe all seem to come later.


SunOS had partitions from the start (1982). These may have been carried
over
from the Ubisoft port, but I've not been able to confirm that. If so, they
date a little
earlier. HP/UX had them in about this same time period, but my sources for
that
are not very good.

Warner



Partitioning as a "slice" probably predates IBM PC DOS v2

Would appreciate some recollections about DEC usage, other minicomputers
and
the BUNCH.

You can either post directly to Wikipedia or let me know; links to
references would greatly be appreciated

Tom

Re: Origin of "partition" in storage devices

[Mike Katz via cctalk]

OS/8 Partitioned the RK05 into 2 (or 4 for the RK05F) partitions due to 
the limitations of 12 bit addressing in the 70's.


On 1/31/2022 7:41 PM, Bill Degnan via cctalk wrote:

OS/8 partitioned RK02 disk packs.

On Mon, Jan 31, 2022 at 2:38 PM Warner Losh via cctalk <
cctalk@classiccmp.org> wrote:


On Mon, Jan 31, 2022 at 12:01 PM Tom Gardner via cctalk <
cctalk@classiccmp.org> wrote:


There is a discussion of the origin of the term "partition" in storage
devices such as HDDs at:



https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22p

artition%22_originate
<

https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22partition%22_originate

?

It seems clear it was used in memory well before HDDs but when it got
started there is unclear.
* IBM PC DOS v2 was an early user in 1983 with FDISK and its first PC
support of HDDs
* UNIX, Apple OS's and IBM mainframe all seem to come later.


SunOS had partitions from the start (1982). These may have been carried
over
from the Ubisoft port, but I've not been able to confirm that. If so, they
date a little
earlier. HP/UX had them in about this same time period, but my sources for
that
are not very good.

Warner



Partitioning as a "slice" probably predates IBM PC DOS v2

Would appreciate some recollections about DEC usage, other minicomputers
and
the BUNCH.

You can either post directly to Wikipedia or let me know; links to
references would greatly be appreciated

Tom

Re: Origin of "partition" in storage devices

[Will Cooke via cctalk]

Partitioning on micros goes back to at least 1979 with CP/M 2.2.
See the CP/M 2.2 alteration guide on bitsavers:
http://bitsavers.trailing-edge.com/pdf/digitalResearch/cpm/2.2/CPM_2.2_Alteration_Guide_1979.pdf

Will

Re: Origin of "partition" in storage devices

[Zane Healy via cctalk]

On Jan 31, 2022, at 11:28 AM, Paul Koning via cctalk  
wrote:
> 
> Both of these are memory partitions.   The only OS I can think of predating 
> the ones you mentioned is RT-11, the later versions (V2 did not have them).  
> When did Unix first get partitions?
> 
>   paul

Partitions are pretty important in RT-11 v5.x, after all, there is the 
partition size limit, so you have to have multiple partitions for almost any 
HD, except very small ones.

Let’s not forget hardware enforced partitioning, the WEQSD/04 ESDI controller 
comes to mind.  It see’s a single large ESDI HD as a single disk, but you can 
partition it on the controller, and the OS sees each partition as a separate 
physical disk.  I seem to remember some MFM controllers that made the MFM drive 
appear to be RL01/RL02 or RK05 packs.

Zane

Re: Origin of "partition" in storage devices

[Chuck Guzis via cctalk]

The IBM 1620 Monitor IID, partitioned the 1311 into various areas.   I
can probably find other old examples.

--Chuck

Re: Origin of "partition" in storage devices

[Bill Degnan via cctalk]

OS/8 partitioned RK02 disk packs.

On Mon, Jan 31, 2022 at 2:38 PM Warner Losh via cctalk <
cctalk@classiccmp.org> wrote:

> On Mon, Jan 31, 2022 at 12:01 PM Tom Gardner via cctalk <
> cctalk@classiccmp.org> wrote:
>
> > There is a discussion of the origin of the term "partition" in storage
> > devices such as HDDs at:
> >
> >
> https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22p
> > artition%22_originate
> > <
> https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22partition%22_originate
> >
> > ?
> >
> > It seems clear it was used in memory well before HDDs but when it got
> > started there is unclear.
> > * IBM PC DOS v2 was an early user in 1983 with FDISK and its first PC
> > support of HDDs
> > * UNIX, Apple OS's and IBM mainframe all seem to come later.
> >
>
> SunOS had partitions from the start (1982). These may have been carried
> over
> from the Ubisoft port, but I've not been able to confirm that. If so, they
> date a little
> earlier. HP/UX had them in about this same time period, but my sources for
> that
> are not very good.
>
> Warner
>
>
> > Partitioning as a "slice" probably predates IBM PC DOS v2
> >
> > Would appreciate some recollections about DEC usage, other minicomputers
> > and
> > the BUNCH.
> >
> > You can either post directly to Wikipedia or let me know; links to
> > references would greatly be appreciated
> >
> > Tom
> >
> >
>

Re: Origin of "partition" in storage devices

[Warner Losh via cctalk]

On Mon, Jan 31, 2022 at 12:01 PM Tom Gardner via cctalk <
cctalk@classiccmp.org> wrote:

> There is a discussion of the origin of the term "partition" in storage
> devices such as HDDs at:
>
> https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22p
> artition%22_originate
> 
> ?
>
> It seems clear it was used in memory well before HDDs but when it got
> started there is unclear.
> * IBM PC DOS v2 was an early user in 1983 with FDISK and its first PC
> support of HDDs
> * UNIX, Apple OS's and IBM mainframe all seem to come later.
>

SunOS had partitions from the start (1982). These may have been carried over
from the Ubisoft port, but I've not been able to confirm that. If so, they
date a little
earlier. HP/UX had them in about this same time period, but my sources for
that
are not very good.

Warner


> Partitioning as a "slice" probably predates IBM PC DOS v2
>
> Would appreciate some recollections about DEC usage, other minicomputers
> and
> the BUNCH.
>
> You can either post directly to Wikipedia or let me know; links to
> references would greatly be appreciated
>
> Tom
>
>

Re: Origin of "partition" in storage devices

[Paul Koning via cctalk]

> On Jan 31, 2022, at 2:01 PM, Tom Gardner via cctalk  
> wrote:
> 
> There is a discussion of the origin of the term "partition" in storage
> devices such as HDDs at:
> https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22p
> artition%22_originate?
> 
> It seems clear it was used in memory well before HDDs but when it got
> started there is unclear.
> * IBM PC DOS v2 was an early user in 1983 with FDISK and its first PC
> support of HDDs
> * UNIX, Apple OS's and IBM mainframe all seem to come later.
> 
> Partitioning as a "slice" probably predates IBM PC DOS v2
> 
> Would appreciate some recollections about DEC usage, other minicomputers and
> the BUNCH.
> 
> You can either post directly to Wikipedia or let me know; links to
> references would greatly be appreciated
> 
> Tom

RSX has partitions; the term goes back at least as far as RSX-11/D.  It may 
well go back to older versions such as RSX-15, but I haven't looked.

OS/360 came in three flavors, PCP, MFT, and MVT.  The OS/360 article describes 
MFT as having partitions selected at sysgen time (the acronym stands for 
"multiprogramming with a fixed number of tasks, with the concurrent tasks 
assigned across the available partitions).

Both of these are memory partitions.   The only OS I can think of predating the 
ones you mentioned is RT-11, the later versions (V2 did not have them).  When 
did Unix first get partitions?

paul