Talk:Hard disk drive interface

Talk:Hard disk drive interface

Technically and historically inaccurate

See "Linux Hardware Compatibility HOWTO" for Kernel 2.2

1.) First Disc surface data protocol was FM or Frequency Modulation (two flux change per bit cell) later improved to MFM or Modified Frequency Modulation (one flux change per bit cell). MFM merged the clock and data (c.f. Manchester encoding) so instead of 2:1 frequency response the disk head amplifiers could also be tuned for a narrower input frequency. RLL or Run Length Limited (RLL 2,7 or RLL 1,9 depending on encoding) determined 2 or 3 bits per "bit cell" based on exact data pulse location yet pulse rate (frequency) was the same. See http://www.datasheetarchive.com/2--MFM+encoder-datasheet.html The read signal from the disk surface was weak analog and disk motor "jitter" sometimes didn't provide an accurate signal for RLL decoding. ST-506 interface was two cables: 34 pin idc for control (shared) and 20 pin idc (per drive) for "data" )actually decoded into data on the controller board example 8/16 bit WD1002-?? or later 16 bit WD1003-?? (the datasheet archive describes WD1100 decoder chips on those boards). The length of these data cables could corrupt the raw data signals (which limited the access to the drives)(note 19" inches is the official maximum cable length spec for IDE). ESDI drives included the data decoder/encoder on the drive itself, faster data rates were then possible on the data cables. ESDI ushered in the use of microcontrollers on the drive itself, previously st506 drives were mechanical only devices like floppy drives. Note that most Floppy and Hard disk controllers worked with a standard interface which was compatible with PC-AT Bios Interrupt 13, many controller cards had onboard Bios that used their own control protocols (like Richoh GSI-8).

2.) Disk controllers XT on, e.g. WD1002-??, WD1003-??, ACB-2370, etc. used Intel i8048 series controller chips. The controller interface that lives today in IDE variants (i.e. SATA legacy mode) used 2 registers for control and data exactly as in the Intel stand alone slave controller (also used in the PC-AT keyboard controller) the i8042. The IDE interface used the AT bus interface because the WD1003 type controller chip was moved to the hard drive.

3.) Early SCSI drives had an Adaptec ACB-4000 series controller board attached to an ST-506 drive. Like earlier ST-506, some boards had emulation support, some had onboard bios controlling the interface (including PC Bios support for scsi chipsets e.g. 53c400, 53c810, AIC-78xx, etc.), or required drivers.

4.) Missing interfaces like iSCSI (ethernet, OSI layer 2), Fiber Channel, Thunderbolt, Parallel port (APA-358, "Backpack" drives, some Zip drives, etc) ... and not to forget Sony 30 pin "SCSI" , Rodime Model 552 hard drive uses a 26 pin socket (Apple II SCSI), and CM 205 16 pin interfaces.

5.) PATA has 2 devices per 40 pin ide interface requiring master and slave designation, requiring data structure on the slave to be compatible with the master controller. Mitsumi and other early CD-rom drives used proprietary data control formats incompatible with disk controllers and all ide accesses went through the CD driver causing latency. A mention of LBA or Logical Block Addressing (Relative Block Addressing for SCSI) (vs Cylinder-Head-Sector addressing) would be important.

6.) ATAPI is important as an interface as it adds SCSI command support to the ATA command set allowing CD-ROM, Tape, and other device support. Most Hard Drives also have ATAPI support evidenced as different platters described as numbered LUNs (SCSI for Logical Unit Number). SATA in addition to IDE or "Legacy Mode" BIOS option usually uses "Native Mode" or AHCI (Advanced Host Controller Interface). Similar to OHCI for USB and Firewire/IEEE1394.

7.) FYI the move from parallel to serial high speed interfaces is due to "bit-jitter" a RF effect where signals that change more often (higher frequency) travel down a wire more slowly than lower frequency signals, resulting in high speed parallel data getting corrupted.

8.) USB Mass Storage Specification allows for storage access without USB to IDE translation. Rasberry Pi computer uses Micro Secure Digital memory card interface directly from the ARM CPU using SD compatibility with SPI (Serial Peripheral Interface).

Shjacks45 (talk) 15:10, 15 April 2013 (UTC)

IMO the above is TMI for this article. Note to be historically accurate, the first Disc surface data protocol was not Frequency Modulation (FM); as best I can recall the RAMAC used a form of NRZ. Again as best I can recall FM was introduced later, perhaps the 1311 or 2311. Either way I don't see anything in the article that is incorrect about this particular bit of history nor do I see anything in the article as "technically and historically inaccurate" - lacking some detail perhaps, but again such detail can be TMI for the target audience. Tom94022 (talk) 17:26, 15 April 2013 (UTC)

NRZI would make sense, as that is what IBM knew how to do on tape, but you still need a clock. For 7 or 9 track tape, there must be at least one transition (B'1') in each character. (That is why even parity isn't a good idea.) That is, it clocks based on at least one track having a transition, but that only works if there is more than one track. Does RAMAC have a two track head? Gah4 (talk) 16:38, 23 April 2016 (UTC)

I seem to recall the IBM 350 had at least one clock track and associated fixed head. But if u really care you can find the manuals at bitsavers and thereby have an RS. The info is probably in a 305 maintenance manual. Tom94022 (talk) 02:34, 24 April 2016 (UTC)

From wikipedia and the associated patent (issued in 1970), it seems that it is NRZ with six data bits, a parity bit, and a space bit. Similar to the way the start bit works for serial NRZ data, it seems to me that the space bit could allow for accurate bit timing. Also, with odd parity (I didn't check) there would be at least one transition per character. And yes, there is a timing track. That would be useful for writing, and for keeping the timing close enough for reading. Unlike tape, the speed stays close enough to constant that it isn't so hard to get the timing right. I also like the four stage differential vacuum tube amplifier on the read head. Gah4 (talk) 08:28, 24 April 2016 (UTC)

To continue this discussion, the start of personal computer disk technology is the floppy disk. While originally designed by IBM to hold microcode, it allowed for a usable, and affordable, storage system for home computers. Note the similarities of the ST-506 interface to the floppy disk interface. That might have evolved to today's hard disk drives, even without the IBM mainframe history. NRZI lasted way too long on tapes, fortunately not so long on disks. Gah4 (talk) 20:55, 8 March 2017 (UTC)

Interfaces speed table

I am looking for comparison of speeds achieved by interfaces, but don´t see any. Does anyone knows that infos and can them add to the article? Thank you. --Robin WH (talk) 14:27, 17 November 2014 (UTC)

For the early drives, most of those used on mainframes, each drive had its own controller, and its own interface. In the minicomputer and microcomputer days, more general interfaces appeared, starting with floppies and then into hard disks. 8 inch floppies run at 250kb/s (FM), or 500kb/s (MFM), and 5.25in floppies at half that rate. ST506 runs at 5Mb/s MFM. The same interface, run with an RLL controller, runs at 7.5Mb/s, as the peak transition rate is the same. ESDI allows for some variability, and so higher bit rates. Gah4 (talk) 16:49, 23 April 2016 (UTC)

controller or not?

It isn't so obvious from most of the discussion that two different interfaces are discussed. One is the interface between the drive (signals to/from heads, and head position movement from/to the disk controller), and the other is the signals between the host processor and the disk controller. Since host to controller interfaces are included, those use between IBM mainframes and their disk controllers should also be included. Gah4 (talk) 07:34, 7 November 2016 (UTC)

A recent revert with the statement: Thus each time the internal technology advanced there was a necessary delay as controllers were designed or redesigned to accommodate the advancement; this along with the cost of controller development led to the introduction of Word serial interfaces. reminds me of this. The article does not properly make the distinction between disk controllers and host bus interfaces. That is, where the bits are decoded. The transition from ST-506 and ESDI, which send raw flux transition data down the wire, to SCSI and ATA which convert flux transitions to data bits in the same assembly as the disks and motors. Changes in relative costs, where there isn't need to share bit decoding logic between multiple drives are the reason for the transition. I suppose also that the majority of today's computers only have one disk drive, and so there is no need to share logic. Otherwise, sharing logic allows one drive to transfer data while others are seeking, making optimal use of expensive (in the early days) logic. Gah4 (talk) 02:42, 7 March 2017 (UTC)

I think the issue is that the meaning of the term "disk drive interface" has changed over time. When controllers were large and expensive there was an exposed and standardized "disk drive interface" between the controller and the disk drive; e.g. SMD or ST506. Today a controller is a small part of a chip and it is integrated into a disk drive's SOS so today's "disk drive interface" has the characteristics of yesterdays controller interface; e.g., Larry Boucher the father of SASI/SCSI says he wanted an interface equivalent to the IBM channel. I think the article is OK as it is since it is about "disk drive interface" and not disk I/O architecture. BTW, there were very few disk drives that had a host bus interface, think Plus Hardcard; all disk drive interfaces today attach thru at least an Host Bus Adapter. Tom94022 (talk) 08:13, 7 March 2017 (UTC)

Well, exposed standardized or not. To start at the top, bus and tag is not the disk interface for S/360. That is the interface to controllers, similar to the way PCI is now. History_of_IBM_CKD_Controllers explains the controllers, and which devices they interface with. The 3830 disk controller can interface with 3330, 3340, and 3350 disk drives. It might be that the actual interfaces to the different drive models are different, such that the 3830 can do all three of them. In the case of SMD, the data separator is in the drive, such that decoded bits go down the cable. The controller still does seeks and recognized sector headers, but bit timing is done by the drive. Yes, host bus adapter is what I meant by host bus interface. Well, in the case of ATA, it is pretty much the ISA bus, with some buffers to increase the drive current, that goes up the cable. Also, in the early days of SCSI, there were boards that interface to ESDI drives, and I suspect also ST-506 drives. I have a floppy drive with a SCSI interface, which is a separate PC board connected to a normal floppy drive. Also, the device independence of IBM's bus and tag still hasn't been reached. A 360 or 370 will IPL off any device that recognizes the X'02' read command: disk, tape, card readers, I suspect also paper tape readers. As far as I know, the PCI commands for disks, tape, and other I/O devices are device specific. Gah4 (talk) 19:45, 7 March 2017 (UTC)

I don't think I stated or even tried to imply "bus and tag is a disk interface for S/360." However, one might argue that since the 3380-CJ2 Direct Chanel Attached DASD exposes an IBM channel interface (bus and tag) there is at least one instance of such a disk drive interface. It is an exception that makes the point.

A host bus adapter has two interfaces, one to a host interface and one to some sort of device side interface. The IBM channel interface (bus and tag) is on the device side and is not a host side interface like PCI; almost each IBM host exposed a different host interface - the channel is common across the line and allowed peripherals of all sorts to be connected across the line. Like SATA and SAS do today. The IBM Channel is just a big (and powerful) host bus adapter :-) While the IBM channel interface might be able to support some things that can't be done with a modern HBA/modern HDD, I think this modern combination is ubiquitous whereas the IBM channel was limited to only IBM type computers i.e., IBM and a few clones).

There were two models of the 3830, the first, Model 1 sat between the channel and a disk drive, that interface to the drive is an early interface very much like SMD. It only supported 3330s, both single and double capacity. The second Model 2 actually split the controller (called Storage Control Unit by IBM) into two pieces, one called the Director and the second called a Controller (unfortunately) with a new interface between them called DCI (Director Controller Interface). Each interface between the drives and its drive specific controller remained an distinct early interface again not unlike SMD but each was different (mainly data rate and track format). The DCI on the other hand is a word parallel interface like SCSI or an IBM channel and the same across several models of IBM Director, see Director type storage controls. Why IBM created this layer in its mainframe I/O structure is another and much longer story

Sure many early devices exposing a new interfaces begin with bridge contollers and for the most part when volume justified it they are integrated over time. Your "floppy drive with a SCSI interface, which is a separate PC board connected to a normal floppy drive." is just a separate controller and FDD in a box; each with separate standard interfaces. I doubt if the there was ever enough volume to integrate them. A bettter examples are both SASI/SCSI and IDE - the very first drives had bridge controllers to ST-506 type interfaces, but the volumes quickly led to them being integrated with no early interface at all.

I'm not sure what this dialog has to do with the content of this article, but it has resurected old memories :-) Tom94022 (talk) 21:20, 7 March 2017 (UTC)

Well, mostly I thought the article should make a better distinction between host-controller interface, and controller-disk interface. Also, bus and tag is more like a host-controller interface, as typically there is a controller between bus and tag and the actual I/O device. The 2501 card reader has the controller logic inside, but the 2540 uses the IBM_2821_Control_Unit between it and the bus/tag cables. The 2821 is about as big as the 2540. For the larger systems, the channel is an actual box with separate hardware. For smaller systems, it is microcode, which shares the CPU hardware. In the latter case, bus and tag are more like a host bus. (As I understand it, the 303x machines use a recycled 370/158 with different microcode for the channel control.) Gah4 (talk) 22:16, 7 March 2017 (UTC)

Maybe we need to work on the lede a bit to explain the evolution of time of the meaning of "disk drive interface?" I think to most readers SAS and SATA are the only known "disk drive interfaces," but at one time they were controller to disk drive interfaces. Tom94022 (talk) 22:55, 7 March 2017 (UTC)

We don't want to turn this article into an I/O architecture article nor do we want to get into OR. I poked around a bit without much luck. The I/O article is really bad and not of much use. Paterson et al, "Computer Organization and Design" really only addresses the two layered architecture (i.e, an I/O Controller between a Memory Bus Interface and a Device Interface, see, e.g., INPUT/OUTPUT ORGANIZATION p. 3, 7 & 13) and ignores other known architectures such as the three layer IBM Channel/Control Unit/DASD, the four layer IBM Channel/Director/Controller/DASD and even the one layer Hardcard (plugs into PC/AT bus). Proably should rewrite the I/O article but in the meantime I'm at a bit of a loss as to how to improve this article. I'm going to keep poking around. Any ideas? Tom94022 (talk) 18:16, 8 March 2017 (UTC)

I think the motivation for my original post to this is that the important part of a disk controller is the data separator. That is the transition from analog (bits can appear anywhere) to digital (only where the clock says that they are). I remember when I was first learning about floppy disk controllers, when buying the first ones for my home computers, that analog (PLL based) data separators were preferred. As far as I know, today's drives use a digital emulation of the analog PLL for the data separator. Early disk interfaces were designed to make optimal use out of the difficult to build data separator, and immediately following logic. Bus and tag is interesting, as it standardizes the interface between computers and I/O devices, in the same way that the Apple II bus, the ISA bus, and PCI did. As electronics evolved, SMD moved the data separator in with the drive. The controller still has to assemble bits into bytes, but synchronous logic is involved. I suppose we could have an article similar to Mains_electricity_by_country, with the bare minimum on the different connectors and what to plug in where. But it is nice to describe at least a little bit about what goes through the different connectors. Note that this article does not mention pinouts, but leaves that to the article for each interface, I believe correctly. But a little discussion here about what is done where would help. It also helps explain the diversity of interfaces. Gah4 (talk) 21:28, 8 March 2017 (UTC)

FWIW, the data separator is not the important part of a disk controller - it is only one part of what distinguishes a dumb HDD interface from a smart HDD interface; the formatter/deformatter, including ECC and defect management are at least as important and IMO they are collectively harder to do. SMD was not the first nor the last dumb interface to move the data separator from the drive to the controller (I think Diablo was first and ESDI was last). According to the oral history of SMD's management team it had little effect (possibly negative) upon the initial acceptance of SMD drives in the market; it still took the industry two years to develop controllers because the data rate and the bits per track went up by a factor of 1.5 over the then "standard" 3330 class of interface (from 13440 bits and .806 MB/sec to 21060 and 1.21 respectively). Just because it is synchronous doesn't mean it is easy as suggested by the SMD experience.

The IBM New Attachement Strategy was at least in part aimed at making expensive Control Units reusable thru "device independance;" that is, by moving the drive dependent electronics into a controller leaving the host related electronics and firmware in the Director. Directors then could be reused thru multiple drive generations. IBM moved it all, data separator, write clock (another PLL), formatter/deformatter, most of the ECC and defect skipping among other drive dependant functions, creating maybe the first intelligent HDD interface. It worked, albeit as a very expensive implementation not adopted by anyone else. The 3830 3880 was reused for three generations of drives and the subsequent 3880 3380 and 3390 supported at least two generations of drives. BTW the development and marketing challenge really is data rate and track format since when one increases only the track density the increased capacity drive can usually be accomodated on an existing controller with minimum firmware (or hardware) changes whereas then the data rate and number of bits per revolution go up lots of things change beyond the center frequencies of the PLL for writing and VFO for reading.

So I think any emphasis on the data separator alone in this article would be misplaced; it is only a part of the story of device independant disk drive interfaces and the data separator location in and of itself has only had marginal impact in the industry. Maybe we could add something about what does distinguish today's intelligent interfaces from the earlier dumb interfaces but we would have to be careful to avoid OR. If we wanted to go that way there maybe some WP:RS's around the introduction of SASI and IDE. Jack Harker's oral history on the New Attachment Strategy might be another good source on what is necessary to achieve device independance in disk drive attachment, However, WP:SYN might become a problem with putting these together. Tom94022 (talk) 22:46, 8 March 2017 (UTC)

I wasn't trying to say that the data separator is most important, but it did come out that way. It is unambiguous, as you have to go from analog to digital somewhere. Good digital designers can make just about anything digital given enough logic. (That is, time, money, and board space.) But, yes, designing an affordable SMD controller is a challenge, and maybe more than a good data separator. The challenge of the data separator is getting analog and digital designers working together. Also, there are stories about how bad the 3880 is, such as being slower than the 3830. (I would have to look up the details, though, so I won't say more about that.) Otherwise, I think you have it the other way around. SMD moved the data separator to the drive. Other things can be moved around. There is a SCSI option to write 520 byte blocks (I suspect you can format for any size, but it seems to be a size that was used). That allows one to do ECC in the host, after the data is out of the controller. (I think that is right, I didn't count the bits. I remember it from the first time I had to format a SCSI disk.) (Sun interfaced Multibus controllers to VME, instead of getting someone to make a VME bus controller. Presumably cheaper and faster than designing and building a VME version.) Gah4 (talk) 23:37, 8 March 2017 (UTC)

Thanks for pointing out the typo, I fixed it. Good PLL (phased locked loop) designers can make any data separator work too and it usually only takes one of them but it takes a whole gang of logic designers to make the rest of the device dependent logic work. ECC can be device dependent and u might not be able to do ECC in a host when you have defect skipping. We used to do bad block mapping and lots of error recovery in the host too - they've mostly gono into the drive today. The whole idea of intelligent interfaces is to make the HDD look like a block of good contiguous data and leave all of the implementation details to the drive designers. Seems to have worked out well. Tom94022 (talk) 07:20, 9 March 2017 (UTC)

Word serial or parallel?

The section describing word serial describes what is usually called parallel. I suppose in cases where each signal line had its own clock, like for example gigabit ethernet, word serial might be more correct, but when the data is clocked with a single clock, parallel better describes the function. Gah4 (talk) 08:38, 7 November 2016 (UTC)

What are the families?

I removed IBM Bus/Tag, ESCON and FICON from the table in Section 1 as these are not hard disk drive interfaces, that is, to the best of my knowledge these interfaces all require a controller of some sort which in turn has a hard disk drive interface to one or more disk drives. The table starts with SMD but I think there are other families where a family is a disk drive interface that was standard across products of two or more manufacturers. It might include:

• IBM 2311 interface, with interface compatible drives provided by IBM, Memorex and other PCMS, all attached to IBM 2841s
• DEC RPO2/3 interface, with interface compatible drives provided by DEC, Memorex, ISS, Century Data and others all attachable to DEC, other DEC compatible controllers and many other minicomputer controllers.
• Diablo interface, with interface compatible drives provided IOMEC and others all attachable to controllers of many minicomputers

These all fall into the early category with a bit serial data interface and a separate control interface.

I didn't include DEC Massbus because to the best of my knowledge all their drives included an embedded controller attached to a drive with the DEC RP02/3 interface and DEC fought very hard to prevent any one else providing drives with this interface (sued and won against SI as I recall). I didn't include DEC SDI for the latter reason but I do believe there are DEC SDI with a native SDI interface, but none offered by any other manufacturer.

Any comments or suggestions before I add the above to the table? Tom94022 (talk) 07:55, 9 March 2017 (UTC)

I think the whole purpose for the article is now the question. As I noted yesterday, it could be like Mains_electricity_by_country as a guide for people who need to know what to plug in where. Then we only need diagrams of the plugs, and the names that go with them. I don't think we should do that, but mention it for comparison. The two or more manufacturers is interesting. But okay, there is the ITEL 7330, compatible with the 3330, but can be attached to S/360. I am not sure if that means a different controller, but I suspect so. As I understand it, the DEC RP-05 and RP-06 are related to the 3330, maybe disk pack compatible, but not drive interface compatible? IDE/PATA is really the ISA bus with address decoding done before the cable, but otherwise most signals go straight through with some TTL buffers. I thought for IBM 3330's that the controller went into one end of the cabinet, such that there are an odd number of drive modules. SCSI and ATA are also used as tape drive interfaces, does that disqualify them here? I don't know the newer IBM drives at all, but I suspect that controllers have moved in with the drives, and that ESCON and FICON are used as the interface with them. I believe that the IBM drives are all emulations of multiples of the 3390, using otherwise standard interfaces inside the box. You aren't supposed to look inside. Hope this helps. Gah4 (talk) 16:50, 9 March 2017 (UTC)

This article hard disk drive interfaces was in October 2012 split from the HDD article to reduce the HDD article's size. Its purpose is to explain the history of such interfaces without going into overall detail. I agree we don't need to list every variation and I think the Mains_electricity_by_country article goes way too far, particularly since it seems redundant to the IEC site. To address your points:

• To the best of my knowledge none of the PCM 3330 disk drive interfaces (e.g.the ITEL 7330 interface) were compatible with the IBM 3330 interface to the IBM 3830-1 interface but instead the PCM drives connected to their own PCM Storage Control Unit using interfaces that were different, perhaps subtlety so, but different. So there was no standard family. Likewise for the 2314/2319. After the 3330 family, IBM went the Director/A-Box/B-Box route in their mainframe and small computer markets where the A-Box was a controller plus a B-Box type drive; again to the best of my knowledge no IBM B-Box drive was ever offered by a second party.
• The RP04, RP05 and RP06 are Massbus devices that literally have a massbus controller bolted onto a conventional disk drive with an interface of the RP02/RP03 class. No integration at all. For example the RP06 (see picture) was a Memorex 677 with a bolt on DEC Massbus controller. As best I recall the 677 was also offered with an SMD type interface probably at a different data rate.
• I agree u don't have to look inside a modern IBM storage system boxes since they are not offered as disk drives directly but instead as storage subsytems. They comprise one or more controllers and many HDDs. If you looked into the box one would find the HDDs in these systems have conventional interfaces like SAS and FC. BTW we may have to add SSA to the family list.

I think we are struggling to find a definition of "family" that keeps us from having to try and list each and every HDD interface ever offered. Note that the table is qualified as "The following table lists some common HDD interfaces in chronological order:." Maybe that is sufficient. Any ideas? Tom94022 (talk) 19:15, 9 March 2017 (UTC)

The 2319 makes it more interesting. It interfaces with the IFA, Integrated File Adaptor, which is included in some low end S/370 models, I believe sharing the processing unit, but otherwise is a recycled 2314. I suspect that means that the interface is different from the 2314, but I don't know that part at all. If the requirement is more than one manufacturer, I suspect that the 2319 is out. While not official, as that wouldn't be encyclopedic, Mains_electricity_by_country is meant for travelers. It doesn't, for example, describe the plugs for air conditioners and electric dryers, as people don't travel with those. If someone opens a computer and wants to know what kind of drive it has, such that they can buy a replacement, this could be the article they check. It is useful to have some of the advantages and disadvantages, as one might want to switch to a different drive interface. We could split again, into traditional and recent disk drive interfaces. The older mainframe drives in the former, newer, small format drives in the latter. Reminds me of the page on Film speed where someone has suggested not including the description of film, as everyone now uses digital cameras. (Even though the article is titled film speed.) Gah4 (talk) 22:34, 9 March 2017 (UTC)

The 2319A has a controller in it plus three drives; attached to it are one or two 2319Bs which do not have the controller, just three of the same drives as in the 2319A, 2313 (4 drives), 2312 (1 drive) and 2318 (2 drives). The HDD interface is a dumb HDD interface, the 2314 interface, which is just like the 2311 although at a higher data rate. To the best of my knowledge no one made a 2319 compatible drive other than IBM. I'm still not sure what needs to be changed in the article other than perhaps adding a few more "common" interface families. Tom94022 (talk) 06:40, 10 March 2017 (UTC)

Agree this is article has errors and is not up to date

Eg There is nothing on PCIe for SSDs on Macs. Is Wikipedia dead? It is so sad, in grad school keeping it up was cool. Wikipedia is in crisis.Iopis (talk) 03:03, 18 June 2022 (UTC)

Not sure there is anything in error in the article so if Iopis knows of any specific errors we would appreciate pointers. Also, it is not so clear that NVMe interface should be added since such an interface is not native to any known production HDD (it is readily available on SSDs). Seagate as talked about such but a quick search can't find any real product so I added it as a non-native interface in this HDD article Tom94022 (talk) 21:54, 18 June 2022 (UTC)