31 Jan
2022
31 Jan
'22
4:35 p.m.
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
31 Jan
31 Jan
4:51 p.m.
On Jan 31, 2022, at 7:35 PM, Noel Chiappa via cctalk
<cctalk at classiccmp.org> 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.
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
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.) 
5:13 p.m.
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 cisin at xenosoft.com
XenoSoft http://www.xenosoft.com
2245 Carquinez Avenue (510) 234-3397
ElCerrito, CA 94530
5:19 p.m.
On 1/31/22 20:13, Fred Cisin via cctalk wrote:
On Mon, 31 Jan 2022, Paul Koning via cctalk wrote:
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
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. 
6:13 p.m.
On 2022-01-31 6:19 p.m., Bill Gunshannon via cctalk wrote:
On 1/31/22 20:13, Fred Cisin via cctalk wrote:
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.
On Mon, 31 Jan 2022, Paul Koning via cctalk
wrote:
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
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. 
10:38 p.m.
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.
1 Feb
1 Feb
8:07 a.m.
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
9:57 a.m.
Sent from my iPad
On Feb 1, 2022, at 10:43, Jon Elson via cctalk
<cctalk at classiccmp.org> wrote:
?On 2/1/22 00:38, Peter Corlett via cctalk wrote:
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.)
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
1:14 a.m.
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
2:02 a.m.
On Tue, 1 Feb 2022 at 10:14, Joshua Rice via cctalk
<cctalk at classiccmp.org> 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: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
5:50 a.m.
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
8:20 a.m.
On Tue, 1 Feb 2022 at 14:50, Maciej W. Rozycki <macro at orcam.me.uk> 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 <paulkoning at comcast.net> 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=T…1023.
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: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
11:40 a.m.
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.
6:20 a.m.
On Feb 1, 2022, at 5:02 AM, Liam Proven via cctalk
<cctalk at classiccmp.org> 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
8:14 a.m.
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
8:17 a.m.
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.johnson at 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
8:26 a.m.
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
antonio at acarlini.com
12:29 p.m.
> 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.
8:21 a.m.
On Tue, Feb 1, 2022, 9:14 AM Jon Elson via cctalk <cctalk at classiccmp.org>
wrote:
On 2/1/22 04:02, Liam Proven via cctalk wrote:
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
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!
9:16 a.m.
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
9:21 a.m.
On Feb 1, 2022, at 12:16 PM, Mike Katz via cctalk
<cctalk at classiccmp.org> 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
9:33 a.m.
On Feb 1, 2022, at 12:21 PM, Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
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 Feb 1, 2022, at 12:16 PM, Mike Katz via cctalk
<cctalk at classiccmp.org> 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.
10:04 a.m.
On Feb 1, 2022, at 12:21 PM, Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
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
On Feb 1, 2022, at 12:16 PM, Mike Katz via cctalk
<cctalk at classiccmp.org> 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. 
10:21 a.m.
On Feb 1, 2022, at 1:09 PM, Glen Slick via cctalk
<cctalk at classiccmp.org> wrote:
On Tue, Feb 1, 2022 at 10:04 AM Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
Which came first CLV CDs, or CLV LaserDiscs?
I forgot about LaserDisc. That's earlier, says Wikipedia.
paul
Slower on the outer tracks, I believe. CDs work
this way.
I suspect CLV was invented for CDs, in fact. 
2:42 p.m.
On Tuesday (02/01/2022 at 01:41PM -0500), Chris Zach via cctalk wrote:
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
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. 
10:42 a.m.
On 2022-02-01 14:09, Glen Slick via cctalk wrote:
On Tue, Feb 1, 2022 at 10:04 AM Paul Koning via
cctalk
<cctalk at classiccmp.org> wrote:
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.
Slower on
the outer tracks, I believe. CDs work this way.
I suspect CLV was invented for
CDs, in fact.
10 a.m.
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
<cctalk at classiccmp.org> 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
10:03 a.m.
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
10:23 a.m.
On Feb 1, 2022, at 1:03 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
On 2/1/22 09:16, Mike Katz via cctalk wrote:
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?
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.
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
1:40 p.m.
New subject: OT: Who? What? Was: Re: Origin of "partition" in storage devices
On Feb 1, 2022, at 4:31 PM, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
On 2/1/22 11:23 AM, Paul Koning via cctalk wrote:
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
Did any DEC MSCP disks use it?
Please expand "MSCP". My brain is failing to do so at the moment. 
1:52 p.m.
New subject: OT: Who? What? Was: Re: Origin of "partition" in storage devices
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
2:08 p.m.
New subject: OT: Who? What? Was: Re: Origin of "partition" in storage devices
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
2:17 p.m.
New subject: OT: Who? What? Was: Re: Origin of "partition" in storage devices
On Feb 1, 2022, at 5:08 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
On 2/1/22 13:40, Paul Koning via cctalk wrote:
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
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. 
2:57 p.m.
New subject: OT: Who? What? Was: Re: Origin of "partition" in storage devices
On 02/01/2022 4:08 PM Chuck Guzis via cctalk
<cctalk at classiccmp.org> 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
3:46 p.m.
New subject: OT: Who? What? Was: Re: Origin of "partition" in storage devices
On 2/1/22 15:40, Paul Koning via cctalk wrote:
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
On Feb 1, 2022, at 4:31 PM, Grant Taylor via
cctalk <cctalk at classiccmp.org> wrote:
On 2/1/22 11:23 AM, Paul Koning via cctalk wrote:
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) Did any DEC MSCP disks use it?
Please
expand "MSCP". My brain is failing to do so at the moment.
4:34 p.m.
New subject: OT: Who? What? Was: Re: Origin of "partition" in storage devices
On Feb 1, 2022, at 6:46 PM, Jon Elson via cctalk
<cctalk at classiccmp.org> wrote:
On 2/1/22 15:40, Paul Koning via cctalk wrote:
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
On Feb 1, 2022, at 4:31 PM, Grant Taylor via
cctalk <cctalk at classiccmp.org> wrote:
On 2/1/22 11:23 AM, Paul Koning via cctalk wrote:
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) Did any DEC MSCP disks use it?
Please
expand "MSCP". My brain is failing to do so at the moment.
11:42 a.m.
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
11:48 a.m.
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.
11:52 a.m.
On Feb 1, 2022, at 2:42 PM, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
On 2/1/22 2:14 AM, Joshua Rice via cctalk wrote:
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
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.
3 p.m.
On Tue, Feb 1, 2022 at 12:42 PM Grant Taylor via cctalk <
cctalk at classiccmp.org> wrote:
On 2/1/22 2:14 AM, Joshua Rice via cctalk wrote:
All modern SSD's firmware that I'm aware of decouple the physical location
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.
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
4:32 p.m.
On Feb 1, 2022, at 6:00 PM, Warner Losh via cctalk
<cctalk at classiccmp.org> wrote:
On Tue, Feb 1, 2022 at 12:42 PM Grant Taylor via cctalk <
cctalk at classiccmp.org> wrote:
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
On 2/1/22 2:14 AM, Joshua Rice via cctalk wrote:
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. 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.
4:50 p.m.
On Tue, Feb 1, 2022 at 5:32 PM Paul Koning <paulkoning at comcast.net> wrote:
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.
On Feb 1, 2022, at 6:00 PM, Warner Losh via
cctalk <
cctalk at classiccmp.org> wrote:
On Tue, Feb 1, 2022 at 12:42 PM Grant Taylor via cctalk <
cctalk at classiccmp.org> wrote:
location
On 2/1/22 2:14 AM, Joshua Rice via cctalk wrote:
All modern SSD's firmware that I'm aware of decouple the physical 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. 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.
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
824
days inactive
825
days old
45 comments
23 participants
participants (23)
-
a.carlini＠ntlworld.com -
abuse＠cabal.org.uk -
bfranchuk＠jetnet.ab.ca -
bill.gunshannon＠hotmail.com -
bitwiz＠12bitsbest.com -
cclist＠sydex.com -
cctalk＠gtaylor.tnetconsulting.net -
chrise＠pobox.com -
cisin＠xenosoft.com -
cube1＠charter.net -
cz＠alembic.crystel.com -
elson＠pico-systems.com -
g4ajq1＠gmail.com -
glen.slick＠gmail.com -
imp＠bsdimp.com -
jnc＠mercury.lcs.mit.edu -
lproven＠gmail.com -
macro＠orcam.me.uk -
paulkoning＠comcast.net -
phb.hfx＠gmail.com -
rice43＠btinternet.com -
spectre＠floodgap.com -
wrcooke＠wrcooke.net