Talk:Hard disk drive

Electro-mechanical

Tom94022 would prefer to describe the subject as a Data storage device. It has for a long time been described as an Electro-mechanical data storage device. The existing description is accurate an more specific than the new proposal so I have reverted these changes twice. Let's discuss here if there is still a disagreement. ~Kvng (talk) 17:17, 13 January 2023 (UTC)

My objective has been to get lede and the short description consistent and accurate; for a long time they have been Electro-mechanical data storage device and Data storage device respectively. A "long time" is not a particularly strong reason to pick either. As the rest of the lede and the article makes clear an HDD stores data magnetically using mechanics and electronics means to access (read/write) the data - an Electo-mechanical magnetic storage device, a more accurate but somewhat unwieldy phrase and quite uncommon. Data storage device" is accurate and consistent with other usages in the article and throughout Wikipedia so it is appropriate for both the lede and the short description. "Electo-mechanical data storage device" is an incomplete description and the term is not used in the article and therefore there is no support for its use in the lede. Tom94022 (talk) 07:29, 14 January 2023 (UTC)

I'm not sure what you mean by unwieldy but "Electo-mechanical magnetic data storage device" is 46 characters so is a reasonable length for a WP:SHORTDESC. The entire phrase does not appear in the body of the article but electronics, mechanisms and magnetic are oft uses words in the article. There are many data storage devices that are not hard disks and I don't see a reason not to be specific if it can be done concisely. ~Kvng (talk) 05:22, 15 January 2023 (UTC)

IMO "Electo-mechanical magnetic data storage device" violates WP:SDJARGON. There are many "Electo-mechanical data storage" devices on Wikipedia so I went and looked at several for some help and was somewhat surprised to find only a few with short descriptions. Most helpful were Tape drive, Videocassette recorder and CD player; none use jargon and the latter two notably are not considered data devices. So this led me to propose a generic short description which might look like this:

Device [storing/playing] [information/data/audio/video/...] on [removable/non-removable/(blank)] [magnetic disk/optical disk/magnetic tape/magnetic drum/semiconductor memory/...]

Specific examples then would read:

Hard disk drive: Device storing data usually on non-removable magnetic disks
Optical disk drive: Device storing data usually on removable optical disks
SSD: Device storing data on non-removable semiconductor memory

Comments from anyone. Tom94022 (talk) 18:36, 15 January 2023 (UTC)

This is progress. I don't think we need or want ususally. The article discusses hard disks with removable media. Let's try, Device storing data on magnetic disks. But that could describe a floppy disk. So, stealing some words from the lead, Device storing data on rigid platter coated with magnetic material. Maybe too long. ~Kvng (talk) 22:13, 15 January 2023 (UTC)

Usually (or typically) as noted is there to deal with the now obsolete cartridge and disk pack disk drives but I can live without it as long as other editors don't want it. How about, Device storing data on non-removable rigid magnetic disk.Tom94022 (talk) 22:50, 15 January 2023 (UTC)

"Electro-mechanical" doesn't seem too jargony to me. I think it's a pretty straightforward combination of the very common and very widely understood words "electrical" and "mechanical". For that reason I also don't think it's a problem for the term not to appear in the body of the article, as it's clearly a summarisation of the electrical and mechanical nature of the device (which is made clear in the article).

We do have an Electromechanics article that it could link to. Barnards.tar.gz (talk) 22:31, 15 January 2023 (UTC)

Whether jargony or not, it doesn't really add any substantive information beyond it being a device whereas the constructs now being proposed do so. We do want to keep the lede and the short description short.

Tom94022 (talk) 22:50, 15 January 2023 (UTC)

I think it neatly summarises the non-solid-state aspect of the device, which is helpful to immediately clarify that the article is not about SSDs, which are the main other type of device in this domain. Barnards.tar.gz (talk) 23:07, 15 January 2023 (UTC)

Yeah, I agree. And it goes with Barnards.tar.gz's comment that electro-mechanical may sound jargon-y but basically any adult would understand what it means.

And, despite what the reply to their comment says, it's not simply "device", but "data storage device", so it does convey all the important info that you'd expect in a one-line description given the context. ~victorsouza (talk) 18:02, 16 January 2023 (UTC)

I'm certainly satisfied with the current SD, "Electro-mechanical data storage device". If I've read these comments correctly, that makes three of us. Can we call this a consensus and be done with this discussion? ~Kvng (talk) 22:39, 16 January 2023 (UTC)

I oppose making it less specific (e.g., Data storage device), but would support making it more specific (e.g., Electo-mechanical magnetic storage device,) --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:32, 17 January 2023 (UTC)

Short descriptions for mobile users and therefore are short; they are "not intended to define the subject of the article, but rather to distinguish it from other similarly named articles in search results."(emphasis added)
Almost all data storage devices have been and still are electro-mechanical in nature so adding "Electro-mechanical" to a short description adds little in distinguishing particularly since the articles "Hard disk drive" and SSD are pretty much distinguished by their titles. Note that the few data storage devices that do have short descriptions do not use "electro-mechanical." So I do think "data storage device" is sufficient for the purposes of WP:SDESC. If we must add text then I would suggest something along the lines used in other "data storage devices," such as Device storing data on a magnetic disk or Device storing data on a rotating magnetic disk. I don't think we have to go as far as Device storing data on a rotating rigid magnetic disk since FDDs are distinguished by the article title. Tom94022 (talk) 19:46, 18 January 2023 (UTC)

You've made that clear but I don't see anyone agreeing with you. I am willing to go along with one of your other more specific proposals but I don't see anyone else taking that up. I also would prefer to avoid long discussions about short descriptions. ~Kvng (talk) 22:24, 19 January 2023 (UTC)

I suggest Device storing data on magnetic disks is acceptable to @Kvng and Chatul: and me so I propose we go with that and then add similar constructs to other data storage devices. Tom94022 (talk) 23:26, 20 January 2023 (UTC)

I supported "Device storing data on rigid platter coated with magnetic material" and Chatul supports "Electo-mechanical magnetic storage device". It's a stretch to go to "Device storing data on magnetic disks" from there. ~Kvng (talk) 16:03, 21 January 2023 (UTC)

Actually I thought it closely meets both criteria since Kvng wrote Let's try, Device storing data on magnetic disks which I adopted and Chatul stated I oppose making it less specific, (e.g., "Data storage device") so this current proposal is Kvng's propsal which I think is minimal, sufficient and consistent between us three editors. FWIW I don't think the word rigid adds anything since the terms "floppy" and "hard" in the titles of those articles are sufficient for the purpose of a short description. Nor do I think there is much difference between "magnetic disk" and "disk coated with magnetic material" other than length. Finally, electro-mechanical adds nothing anything since SSD and HDD are clearly distinguished by their article titles. KISS - Keep it Short & Simple should apply. Tom94022 (talk) 18:21, 21 January 2023 (UTC)

BTW, my problem with "disk coated with magnetic material" is illustrated by the various optical devices. For example, would Magneto-optical drive have a better short description of "Device storing data on an optical disk" or of "Device storing data on a rigid plastic disk coated with a magnetic material for storage and read optically."? I think the former. It would be even more challenging with the various material composition of CD or DVD disks. My original suggestion is that we try and agree upon a generic construction here and then fix the many data storage device articles lacking a short desc. Tom94022 (talk) 19:35, 21 January 2023 (UTC)

"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)