Talk:Hard disk drive

"Medium sized refrigerator"?

I reiterate my edit summary - when did the refrigerator become a standard unit of measurement? What exactly is a "medium" refrigerator - or indeed two, or three of them? The only size reference is for the 350, which states Assembled with covers, the 350 was 60 inches long, 68 inches high and 29 inches deep and is then converted into 68cubic feet in the article - which is a source ok, so why are we not using that instead of refrigerators? Chaheel Riens (talk) 06:54, 9 June 2023 (UTC)

The cubic foot dimension is used, but in an era of HDDs that one can hold in one's hand, refrigerator gives context to the size of cu ft/ltr (standard unit of measures} and noted the size is reliably sourced; "bigger than a bread box bread-basket," another well used comparison would be too small a comparison. There is no assertion that a refrigerator is anything other than a refrigerator and raising that it is not "a standard unit of measurement' is a strawman argument. Furthermore as one tag, as inserted, challenged the standard measurements which are well sourced. I did make the physical comparison the same throughout. Tom94022 (talk)

I'm sorry, I didn't realise that bread-basket was also a valid unit of measurement. How many bread-baskets to the refrigerator? I've heard it said that Americans will do anything to avoid the metric system, but never thought I'd see it here. You're absolutely correct that a refrigerator is anything other than a refrigerator - but there are many, many different types and sizes of refrigerator, and I'm pretty sure that whatever counts as a medium refrigerator in America in the 1950s is not what the rest of the world would recognise as a medium sized refrigerator today in 2023. Why are you so against using actual measurements? Chaheel Riens (talk) 19:27, 9 June 2023 (UTC)

There are many such examples of size in context rather than specific standard measurements, how about bigger than a football pitch (UK English) or a football field (US English)? Why are you so opposed to putting the size in context? Note no specific disk drive dimensions are given at all in the article so I'm not sure why we would want to add them now for just the few drives that have size in context (note there is a "washing machine"; seems like such detailed information belongs in List_of_disk_drive_form_factors not here. Tom94022 (talk) 21:32, 9 June 2023 (UTC)

Recentism

@Tom94022: Edit permalink/1212434580 changed perform reads and writes on demand from the disk controller. to transfers data to/from a disk controller thru a buffered interface., which is true for contemporary disks but false for older disks. I reverted that change, and Tom94022 then changed it first to and transfers data to/from a disk controller thru a interface which in modern drives is buffered., which is correct, but then in edit permalink/1212639168 removed the qualifying phrase which in modern drives is buffered., rendering it again incorrect. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:42, 10 March 2024 (UTC)

With all due respect the sentence as currently written is about and correct with respect to HDD controllers. All hard disk drive controllers required a buffer since almost all drives since RAMAC have been bit serial but the controllers are at least character wide transfer requiring as a minimum a character buffer. With CRC and ECC the buffers got bigger. Historically the controller and the drive were physically distinct and the buffer was in the controller. Today the controller and drive are in the same box but the buffer is still there, still more a part of the controller than the bit serial drive and much larger to provide caching capability. Tom94022 (talk) 17:51, 10 March 2024 (UTC)

No, it is not correct with respect to older drives unless you consider assembling bits into characters to be buffering; the disk controllers on the IBM 7000 series transmitted 6 or 8 bit bytes to the channel and had no ability to buffer records. This remained true on the S/360, with the exception of the Airline Buffer, and remained true on the S/370 until the 3880-- and 3880-13. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:45, 10 March 2024 (UTC)

I think you are confusing controllers (storage control units in IBM's vernacular) with drives and buffers with caches. The Airlines Buffer was a cache in the 2314 control unit and caches were explicitly named as such in the models of the 3880 and later storage control units. But IBM control units for the early drives were buffered both at the channel side and by the SERDES on the drive side. Tom94022 (talk) 19:21, 10 March 2024 (UTC)

No. Regardless of the nomenclature, the only buffering for the older disks was assembly/disassembly of bits in a byte (character) register only wide enough for one interaction with the channel. Assembly/disassembly of characters (bytes) into and out of words and blocks was done by the channel. Only the 2314/2844 Multiplex Storage Control Feature (RPQ number S50001), the 3880 and the 3990 had more than 16 bits of buffering outboard to the channel. That was equally true whether the electronics were packaged in the drive or in the control unit. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:17, 11 March 2024 (UTC)

So you agree there was some small amount of buffering in all early IBM Storage Control Units (not in the drives themselves). FWIW, as soon as Storage Control Units had ECC there had to be at least a full track buffer for correction. Prior to that there were small buffers on the channel side to prevent overruns. Enough said? Alternatively, how about getting rid of buffers all together - I only added it to get rid of a malformed addition about buffers. Tom94022 (talk) 17:10, 11 March 2024 (UTC)

But limited to the channel width.

• No, at least one channel width buffer, could be multiples of the channel width like in a double buffer. Tom94022 (talk) 18:49, 11 March 2024 (UTC)

  You're probavly thinking of the 2835-1/2305-1; the 2-byte interface feature used two bus cables and one tag cable, giving it a width of 16 bits; there was no double buffer. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:25, 11 March 2024 (UTC)

• Nope, I thinking of the 38303380 class SCU and I seem to recall a two byte buffer on each of the several channel interfaces. Tom94022 (talk) 06:22, 12 March 2024 (UTC)

  The 3380 and 3880 came much later. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:15, 12 March 2024 (UTC)

• The 38303380 was a year after the 2835; it used the same microprocessor and much of the same hardware as the 2835. The 3880 was much later. Tom94022 (talk) 17:48, 12 March 2024 (UTC)

  My The 3380 and 3880 came much later. was in response to you original text, before you changed 3380 (a drive) to 3830 (a control unit, much earlier than the 3380 and 3880). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:00, 13 March 2024 (UTC)

ECC does not require full track buffers. It does require full cell buffers, but the cells for error checking were typically much smaller than a track, and didn't exist in the early years.

• It all depends upon the implementation of the correction, on the fly or out of buffer. My recollection is that IBM SCUs with ECC had at least a full key buffer (255 bytes) since those corrections were not on the fly. Likewise I am pretty sure ECC required a buffer at least as long as the correction code. Tom94022 (talk) 18:49, 11 March 2024 (UTC)

  On the 2305 it is on the fly; an error causes command retry and you lose a revolutuion. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:25, 11 March 2024 (UTC).

• On all those early ECC implementations, ECC errors caused a command retry and you lose at least one revolution, but when reconnected the SCU could either reconnect, restart the read and correct on the fly or reconnect, restart the read out of corrected information in a buffer. I am certain on the 3380 class the read was out of buffer for key fields, but I am less certain about data fields. Tom94022 (talk) 06:22, 12 March 2024 (UTC)

  The 3380 and 3880 came much later. Also, the 3880 still uses command retry. Could you be thinking of the optional Speed Matching Buffer? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:15, 12 March 2024 (UTC)

• No I am not. FWIW, the 38303380 was a year after the 2835. The 3880 was much later. Tom94022 (talk) 17:48, 12 March 2024 (UTC)

  Yes, the 3830 was a year after the 2835, but it wasn't the one with the speed matching buffer. My much earlier was in reference to early ECC implementations, and those were the 2305 and 3330. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:00, 13 March 2024 (UTC)

• You are correct about ECC on the count and key; there is a buffer for ECC correction. It is only the data area that does not have a buffer. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:33, 13 March 2024 (UTC)

Yes, removing the reference to buffering resolves the issue, as does moving it to appropriate places in the History section. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:16, 11 March 2024 (UTC)

• Do as you wish. Tom94022 (talk) 18:49, 11 March 2024 (UTC)

Notes

Section on manufacture?

Should there be a section on the manufacturing process of hard drives? I noticed there's a section on the manufacture of the platters in the Hard disk drive platter article, but I feel like this section is a bit technical at a first glance and I imagine that it would be more beneficial for the average curious reader (such as myself) to have a simpler and more accessible overview of the manufacturing process.

I'm pretty new to editing Wikipedia, so I'd appreciate some advice! /home/gracen/ (yell at me here) 15:46, 23 October 2024 (UTC)

A Manufacture section in this article to discuss the non-platter manufacturing process sounds like a good improvement. It might also be helpful to make a similar improvement to Disk read-and-write head. What specific advice are you looking for? ~Kvng (talk) 19:52, 12 January 2025 (UTC)

Oh, at the time I was just looking for advice / general pointers for expanding an article with new information rather than just fixing up existing information. I think I have a better grip on this now that I'm a couple hundred edits in, but if you still have any advice feel free to send it my way! /home/gracen/ (they/them) 21:08, 13 January 2025 (UTC)

More citations needed in integrity section

It seems to me that the "Integrity and failure" section is very poorly sourced. For instance, the first 4 paragraphs, while constituting a significant portion of the body text, only have four citations. I don't really have much to say at the moment as I haven't properly researched the topic to add more sources yet, but I felt it was valuable to have a place for collaboration (it's very frustrating to see a generic maintenance template without any additional information). /home/gracen/ (they/them) 16:10, 30 January 2025 (UTC)