That's a bit different. It's possible that some early Unix machines had actual drum devices for storage or swap (did any of them?), but the /dev/drum device is what Clem says it was. It's funny, I just happened across this a couple of days ago when I went looking for the `hier.7` man page from 4.4BSD-Lite2: https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=7&… It refers to this: https://www.freebsd.org/cgi/man.cgi?query=drum&sektion=4&apropos=0&… The claim is that it came from 3.0BSD. Why was it called drum? I imagine that's historical license coupled with grad student imagination, but I'm curious if it has origin in actual hardware used at UC Berkeley. Clem, that was roughly your era, was it not? - Dan C. On Fri, Apr 20, 2018 at 12:00 PM, David Collantes <david(a)collantes.us> wrote:

On Fri, Apr 20, 2018 at 10:12 AM, Dan Cross <crossd(a)gmail.com> wrote: http://www.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/sys/sys/vmdrum.c So there's something called drum in 3BSD. Haven't chased down the MAKEDEV and config glue to turn it into /dev/drum, but it's enough to support the 'It originated in 3BSD'. It certainly wasn't in 32V since that had no paging. This was 1980. Drum memory stopped being a new thing in the early 70's. So it was just recently obsolete. But its typical use was a very small, but very fast, hard drive to swap things to. There never was a drum device, at least a commercial, non-lab experiment, for the VAXen. They all swapped to spinning disks by then. Warner - Dan C.

On Fri, Apr 20, 2018 at 3:17 PM, Ron Natalie <ron(a)ronnatalie.com> wrote: ​And big and did I say really *noisy* .... We had 4 of them and they so so noisy CMU partitioned the machine room so they they were by themselves. The CPUs and the operators were on the other side of glass wall. ​I was looking at an old pic of me in the CMU machine room circa '76. You can see console to the 1108 and the top of the door to the 'Fastrand' room (which was also the Vax serial #1 was for space reasons); but unfortunately one of the 360/67's 1Meg memory units (we had 4 - each a was a little larger than Vax 780 cabinet) is in the way, so the drums can not been seen. One thing I'll never forget was when the first time they powered up CMU's first KL10 (which was DEC's first ECL based system). It too was an early unit and DEC Pittsburgh had not been trained on them yet. Unfortunately, the on-site provisioning was mistakenly set up for a KA10, which was horribly insufficient. Well, the tech's blew every circuit breaker in the building - shutting down everything. The emergency lights came on and room was eerily quiet, not a single fan running, but there was this strange humming coming from Fastrand room. There was so much stored energy in the drums, they keep spinning for a very long time. ᐧ

Dan Cross wrote: Seems like the Project Genie 940 at UCB had a drum. Maybe someone wanted to carry the tradition forward.

On Sun, 22 Apr 2018 13:37:27 -0400 Clem Cole <clemc(a)ccc.com> wrote: I have wondered if the word "kernel" got used instead of "core" for the essential part of an OS because core was already in use in relation to memory (and with a different derivation). "kernel" may have been used in this context in the '60s but I don't really know who used it first.

Im not sure how you got there. I hardly said or implied that Unix started in 78 or on the Vax. I’m fairly aware that Ken had core in his PDP-7, as did many of us (including myself) on our many of PDP-11s in the old times. I started with Fifth and Sixth Edition. Dumping core had meaning to all of us in those days. All I said was that by the time of the VAX - which very much did spread the gospel of Unix to the world - core memory had fallen from favor and widespread use. The PDP11 was the last system DEC released core. BTW if you want to be correct about dates - the DEC released the Vax in 76 not 78 ( I personally used to program Vax serial #1 at CMU under VMS 1.0 before I was at UCB which is what Dan had asked). Also FWIW. Bill and Ozzie whom I knew from my UCB days, did not do the UCB Vax work until a few years later when the UCB EECS Dept got their first Berkeley VAX and Prof Fateman who had come from MIT wanted to run MAC Lisp on it - which very much required VM support. V32 ( the V7 port for the Vax from AT&T) swapped. Bill and Ozzie added paging support which was released as BSD 3.0 (Ozzie graduates and left for Cornell as I recall but where he went is fuzzy in my memory now). Primarily Bill but with the help of us others followed quickly with 4.0 and 4.1 (the later being the first wide spread Vax release) with his Fastvax support. Later still in the early 1980s Bill lead the CRSG team and released 4.1a/b/c. Bill left for Sun and I left for Masscomp. Kirk, Sam and Keith pushed out 4.2 et al to the final NET2 release which was after my time. Of those on the list from UCB which was my time there was also Mary Ann Horton in EECS and Debbie S. who was up the hill at LBL and who both also sometimes reply - I do look to them correct/affirm me for UCB history. But I personally go back in Unix history to the early/mid 1970s at CMU. I often defer to Noel C for memories of networking things which he was a part at MIT from the same time frame. I defer to Doug, Steve and obviously Ken for things at ATT and history before Fifth Edition. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.

On Sun, Apr 22, 2018 at 2:51 PM, Dave Horsfall <dave(a)horsfall.org> wrote: I'm a mere 52, but I believe paging is preferred over swapping. Swapping is an entire process at a time. Paging is just a page of memory at a time - like 4K or something thereabout. BTW: I love Linux :) at least until something better comes along.

On 25 Apr 2018, at 13:18, Ronald Natalie <ron(a)ronnatalie.com> wrote: Do systems with huge pages page in the move-them-to-disk sense I wonder? I assume they don't in practice because it would be insane but I wonder if the VM system is in theory even willing to try. Something I never completely understood in the paging vs swapping thing was that I think that systems which could page (well, 4.xBSD in particular) would *also* swap if pushed. I think the reason for that was that, if you were really short of memory, swapping freed up the process structure and also the page tables &c for the process, which would still be needed even if all its pages had been evicted. Is that right?

On 25 Apr 2018, at 15:02, arnold(a)skeeve.com wrote: Well, I think because the situations where you are using huge pages and the situations where you're paging to backing store should really be mutually exclusive: if your system is paging to backing store you have problems which huge pages are not going to solve.

So is this also /dev/drums? https://www.youtube.com/watch?v=_pe6r06EIz0&feature=youtu.be -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On 4/25/18, Ronald Natalie <ron(a)ronnatalie.com> wrote: On the VAX, pages were 512 bytes, the same size as a disk record. In my book, virtual memory is any addressing scheme where the addresses that the program uses are different from the physical memory addresses. Nowadays most OSes use a scheme where each process has its own virtual address space, and virtual memory is demand-paged from backing store on disk. But there have been other schemes. Some PDP-11 models had a virtual addressing feature called PLAS (Program Logical Address Space). The PDP-11 had 16-bit addressing, allowing for at most 64K per process. To take advantage of physical memory larger than 64K, PLAS allowed multiple 64K virtual address spaces to be mapped to the larger physical memory. Sort of the reverse of the usual virtual addressing scheme, where there is more virtual memory than physical memory. IBM Disk Operating System for the System/370 (DOS/VS) had a single virtual address space that could be bigger than physical memory and was demand-paged. This address space could be divided into up to five partitions, each of which could run a program. Each partition thus represents what we now call a process. IBM OS/VS1 and OS/VS2 SVS also had a single virtual address space shared by all tasks (processes). OS/VS2 MVS had the modern concept of a separate virtual address space for each process. Gene Amdahl was not a fan of paging. He said that virtual memory merely magnifies the need for real memory. -Paul W.

My favorite is due to Dave Clark at MIT: “Anytime someone says ‘virtual’ you should think ‘slow’” followed closely by “Any problem in computer science can be solved by adding a layer of abstraction” and “Any performance problem can be solved by removing a layer of abstraction.” As one converted to the HPC cults, I am naturally opposed to small pages, virtual anything, and interrupts… -L

This is what we did at Fortune Systems for our 68k based v7 system. There was an external “mmu” which added a base value to a 16 bit virtual address to compute a physical address. And compared against a limit. There were four base,limit pairs that you had to rewrite to context switch: Text, data, spare and stack. At a minimum the system shipped with 256KB so you could have a number of processes memory resident. You swapped out a complete segment when you ran out of space. I imagine other 16bit word size machines of that era used similar schemes.

Ø Well, I had known but forgotten in fact. There's also a distinction between whether a system swaps/pages onto a dedicated device and whether it exposes that device by some special name in /dev. I’m pretty sure that swapping in V6 took place to a major/minor number configured at kernel build time. You could create a dev node for the swap device, but it wasn’t used for the actual swapping.

RK05’s were 4872 blocks. Don’t know why that number has stuck with me, too many invocations of mkfs I guess. Oddly, DEC software for some reason never used the last 72 blocks. We used to the standalone ROLLIN to make backup copies of our root file system and I remember having to patch the program to make sure it copied all the blocks. Yeah, I remembrer swaplo and swapdev. We actually dedicated a full 1024 block RF11 fixed head to the system in the early days until we got the system of RK05 packs. I remember buying my personal RK05 pack for $75 thinking that was a lot of personal storage (2.4MB!). Amusingly, JHU believe in vol copy for backups. Our 80 Mb drive was divided into multiples of RK05 pack. The root file system was 5x4872 blocks. The main user file sytem was another 5. The rest was divided up into single RK05 size things. I remember writing a standalone volcopy to replace ROLLIN that was called “The Fabulous Amtork” program. The 80M drive was an Ampex. AM to RK, get it. I have no idea when or why the adjective “fabulous” became associated with it but that was what it was always called.

On Wed, Apr 25, 2018 at 10:02 AM, Tom Ivar Helbekkmo via TUHS < tuhs(a)minnie.tuhs.org&gt; wrote: ​Right - back in the day, certainly for RK05's we would purchase 'perfect' media, because the original Unix implementations did not handled bad blocks. You had to be careful, but you could purchase perfect RP06 disk packs from one or two vendors. That got harder to do as the disks got larger *i.e*. the RMxx series. A disk pack pack typically shipped with either a physical piece of paper or a sticker attached to them with the HD/CLY bit offset and/or if pre-formatted HD/CLY/SEC of an bad spots (int he old days disks used different formats depending on the controller and different sector sizes, meta data etc, so the bad spots were listed a bit position per ring). A typical thing that a number of us did if we did not have a perfect pack was, after we did the Unix mkfs, manually create a file in either root, or lost+found called bad_blocks, and then using fsdb or the like, assign the blocks that file. The problem was the concept of 'grown' bad spots. I'll stay away from the argument if they were possible or not (long story), but if in practice a pack ended up with a block that was causing issues after it was deployed (which did happen in practice). You needed to assign the bad block to the bad_block file manual. BAD144 was a scheme DEC had to reserve a few blocks and then map out any bad sectors. The problem of course, was that it screwed up all the prediction SW in the OS, as system would ask for block/cyl/sec - X/Y/Z and it could force a head seek to the of the drive to get one of those reserved blocks in the end of the disk. The advantage of the DEC scheme was the during formatting the known bad sectors would become 'invisible' and of course if the pack 'grew' and error the driver could add it to the list and replace the block on the fly (assuming there were available blocks in the reserved table). An interesting story on BAD144 - a good example of the original ideas of Open Source. It was actually the DEC 'Telephone Industries Group" in Merrimack, NH (*a.k.a.* TIG) that had Armando, Fred Canter *et. al.* that wrote the original support for DEC Standard 144; to help support the AT&T customers, pre Ultrix (remember for a long time AT&T was DEC'S largest customer). Once written, that code was also given to CRSG and released into the wild via the UCB stream (and of course would become part of Ultrix when DEC finally 'supported' UNIX officially). I've long ago forgotten, but aps might remember, I think is Fred that did the original work. ᐧ

On Mon, Apr 23, 2018 at 4:47 PM, Grant Taylor via TUHS &lt;tuhs(a)minnie.tuhs.org ​It was not BSD - it was research. It may have been in 6th, but it was definitely in 7th. Cut/pasted from the V7 PDP-11 rp(4) man page: *NAME* rp − RP-11/RP03 moving-head disk *DESCRIPTION* The files rp0 ... rp7 refer to sections of RP disk drive 0. The files rp8 ... rp15 refer to drive 1 etc. This allows a large disk to be broken up into more manageable pieces. The origin and size of the pseudo-disks on each drive are as follows: disk start length 0 0 81000 1 0 5000 2 5000 2000 3 7000 74000 4-7 unassigned Thus rp0 covers the whole drive, while rp1, rp2, rp3 can serve usefully as a root, swap, and mounted user file system respectively. The rp files access the disk via the system’s normal buffering mechanism and may be read and written without regard to physical disk records. There is also a ‘raw’ interface which provides for direct transmission between the disk and the user’s read or write buffer. A single read or write call results in exactly one I/O operation and therefore raw I/O is considerably more efficient when many words are transmitted. The names of the raw RP files begin with rrp and end with a number which selects the same disk section as the corresponding rp file. In raw I/O the buffer must begin on a word boundary.​ ᐧ

On Mon, Apr 23, 2018 at 5:14 PM, Dan Mick &lt;danmick(a)gmail.com&gt; wrote: Yup -- disk were pretty expensive in those days ($20-30K for a <100M drive) so often people did not have more than one. So they started with rp1, rp2 etc.. As disks dropped a little cheaper and having more than one RP06 became possible (RP06 aka IBM 3330 - project Winchester -- was a huge 200M drive - we had 3 on the Teklabs machine and that was considered very, very generous), then letters became the convention used in /dev/. i.e. /dev/{,r}rp0{a,b,c,d..} for each of the minor numbers. To be honest, I really don't remember - but I know we used letters for the different partitions on the 11/70 before BSD showed up. The reason for the partition originally was (and it must have been 6th edition when I first saw it), DEC finally made a disk large enough that number of blocks overflowed a 16 bit integer. So splitting the disk into smaller partitions allowed the original seek(2) to work without overflow. V7 introduced lseek(2) when the offset was a long. Clem ​ ᐧ ᐧ

On 4/23/18, Greg 'groggy' Lehey &lt;grog(a)lemis.com&gt; wrote: The 3330 was, as you say, a conventional (for the day) disk drive where the heads remain with the drive and you removed the platters with a plastic cover very much like a cheese bell. The 3340 was the first IBM drive where the heads were sealed with the media. The disk packs looked somewhat like the front end of the Starship Enterprise, with something like a roll-top desk cover at the back. You put the pack in the drive, the drive opened the roll-top desk and plugged into the back of the head assembly, and you were in business. After a few years IBM discovered that nobody was removing their disks anymore, and so the 3340's follow-ons were not removable. But they still used the sealed-media technology still in use in hard drives today. Regarding the Winchester code name, I've argued about this with Clem before. Clem claims that the code name refers to various advances in disk technology first released in the 3330's disk packs. Wikipedia and my own memory agree with you that Winchester referred to the 3340. -Paul W.

On Tuesday, 24 April 2018 at 9:13:41 -0400, Clem Cole wrote: Hmm. The earliest 3330s had 100 MB per disk, considerably more than the 3340. I had thought that the 3340 had fewer surfaces. And the 3330s definitely only had one disk per unit, though they brought out an 8-drive cabinet with a whopping 2.4 GB (by the time I used them). Yesterday I suggested that CDC might have used the same disk packs as the 3330, but I'm now very sure that the ones we used came from Ampex. It would also be interesting to hear if he can shed any light on the Winchester Boulevard vs. 30/30 controversy. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA

On 23 Apr 2018, at 21:47, Grant Taylor via TUHS &lt;tuhs(a)minnie.tuhs.org&gt; wrote: There is a wonderful Sun cretinism about this. At some recent time (I am not sure how recent but probably mid 2000s), someone worked out that you wanted swap to be at one end of the disk (I think the outside) because on modern disks the data rate changes across the disk and you wanted it at the end with the highest data rate. But lots of things knew that swap was on s1, the second partition. So they changed the default installation tool so the slices of the disk were out of order: s1 was the first, s0 the second, s2 was the whole disk (which it already was) and so on. This was enormously entertaining in a bad way if you made the normal assumption that the slices were in order. There was also (either then or before) some magic needed such that swapping never touched the first n blocks of the disk where the label and boot blocks were, and it was possible to get this wrong so the machine would happily boot, run but would then fail to boot again, usually at a most inconvenient time. And the cretinism was that this was mid 2000s: if you had machine that was paging the answer was to buy more memory not to arrange for faster swap space: it was solving a problem that nobody had any more.

On 04/23/2018 04:15 PM, Warner Losh wrote: I think manufacturers have switched things around on us. I'm used to higher LBA numbers being on the outside of the disk. But I've seen anecdotal indicators that the opposite is now true. -- Grant. . . . unix || die

On Tue, 24 Apr 2018, Michael Kjörling wrote: [ ... ] Exactly; with disks these days it's pointless trying to second-guess what's happening under the bonnet (ObUS: hood). A well-known question in the security field, for instance, is how do you know that you have *really* erased that disk? The thing can lie as much as it likes, and you'll never know for sure. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

On 4/24/2018 5:37 AM, Michael Kjörling wrote: To make it even worse in terms of trying to figure out what a disk will do for (to) you in terms of performance... A new caching scheme on a set of 10TB drives I bought a while ago - they are HGST SAS drives. They incorporated a set of cylinders spaced across the disk that are "cache" cylinders. Wherever the heads are "right now", the closest cache cylinders will be used to write to. Once there's enough free time, it will go back and read those cache cylinders, and put the blocks where they are "supposed" to be. http://www.tomsitpro.com/articles/hgst-ultrastar-c15k600-hdd,2-906-3.html Those are not the drives I bought, but as far as I know, even their near-line SAS products have this feature, called NVC Quick Cache ak

On Mi, 2018-04-25 at 11:31 +1000, Greg 'groggy' Lehey wrote: I kept the manual of the first hard disk drive that I ever integrated into a microcomputer system. This was a Shugart SA600 Fixed Disk Drive; the OEM manual is Copyright 1981. It had the (then) common 5.25" form factor, and could store 8 Mbytes on non-replaceable platters with 6 surfaces. Figure 2-4 in the manual shows the disk surface. "TRK 000" is the outermost track, "TRK 159" the innermost one. Even closer to the spindle is the "Head Shipping Zone" on "TRK 182", which could be accessed by a regular seek. Finally, section 4.4.1 explicitly states that the interface signal "Track 00" is true only when "the read/write heads of the selected drive are at track 00 (the outermost track)". Hellwig

@Fortune Systems we kept a forwarding map of bad blocks. This was stored in a file at inode#1 IIRC. To read/write block n you check if n was in the list. If not, you read/write disk block n. Else you use the mapped block. The last N blocks were reserved for this. Actually we had to keep some state. A block that gave an error on read was marked bad so that further reads errored out. But a write to such a block would allocate a new block and add an entry in the bad block forwarding map. Further read/writes would then Go to this block. I also kept soft (correctable) error stats. These blocks were more likely to go bad so periodically a background task would preemptively forward these blocks. To test this logic I used to build the v7 kernel on a very unreliable disk! But this slowed things down a lot - having to seek to the end zone and then back for the next block. I think in later disk drives an extra block per track was reserved for this and the drive took care of this. It would’ve made more sense to avoid this forwarding by exposing bad blocks to the file system layer so that it can avoid allocating them but this would’ve complicated the interface.

On 4/27/18, Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote: That's the one. I'd always heard "noodle picker", though. From the outside it looked like a drum in the shape of a multi-sided polygon. Each bin held a number of wide pieces of multitrack magnetic tape. To seek to your data, the drum rotated under a head that pulled the appropriate tape out of the bin and wrapped it on rotating drum. From there reading and writing was much like any other drum device. It's as if someone asked Rube Goldberg to design a disk drive. -Paul W.

On 4/23/2018 6:07 PM, Tim Bradshaw wrote: Wow, I was going to refute this, as I don't ever remember seeing any Solaris box do this. However, a Solaris 8 x86 vanilla install on VMware I did recently does indeed have swap on the first cylinders (see below). A Solaris 7 x86 install does not exhibit this behavior. Now I'm wondering if Solaris 9 does it. A Solaris 10 box I have access to has swap after root, not before. # format Searching for disks...done AVAILABLE DISK SELECTIONS:        0. c0d0 <DEFAULT cyl 22166 alt 2 hd 15 sec 63>           /pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0 Specify disk (enter its number): 0 selecting c0d0 Controller working list found [disk formatted, defect list found] Warning: Current Disk has mounted partitions. FORMAT MENU:         disk       - select a disk         type       - select (define) a disk type         partition  - select (define) a partition table         current    - describe the current disk         format     - format and analyze the disk         fdisk      - run the fdisk program         repair     - repair a defective sector         show       - translate a disk address         label      - write label to the disk         analyze    - surface analysis         defect     - defect list management         backup     - search for backup labels         verify     - read and display labels         save       - save new disk/partition definitions         volname    - set 8-character volume name         !<cmd>     - execute <cmd>, then return         quit format> part PARTITION MENU:         0      - change `0' partition         1      - change `1' partition         2      - change `2' partition         3      - change `3' partition         4      - change `4' partition         5      - change `5' partition         6      - change `6' partition         7      - change `7' partition         select - select a predefined table         modify - modify a predefined partition table         name   - name the current table         print  - display the current table         label  - write partition map and label to the disk         !<cmd> - execute <cmd>, then return         quit partition> pri Current partition table (original): Total disk cylinders available: 22166 + 2 (reserved cylinders) Part      Tag    Flag     Cylinders         Size Blocks   0       root    wm    1113 -  3704        1.17GB (2592/0/0)   2449440   1       swap    wu       3 -  1112      512.18MB (1110/0/0)   1048950   2     backup    wm       0 - 22166        9.99GB (22167/0/0) 20947815   3 unassigned    wm       0                0 (0/0/0)            0   4 unassigned    wm       0                0 (0/0/0)            0   5 unassigned    wm       0                0 (0/0/0)            0   6 unassigned    wm       0                0 (0/0/0)            0   7       home    wm    3705 - 22166        8.32GB (18462/0/0) 17446590   8       boot    wu       0 -     0        0.46MB (1/0/0)          945   9 alternates    wu       1 -     2        0.92MB (2/0/0)         1890