![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
HBA vs RAID Card?
- Thread starter AMD_Gamer
- Start date
HBA typically refers to a Fibre Channel interface. Think of it as a NIC card, but for FC. This gives you access to a storage array connected to a fibre channel network, and this network is typically called a "fabric". It can also get you access to direct access disks, but fabrics are more common these days.
A RAID card is for local direct-attached storage.
A RAID card is for local direct-attached storage.
HBA = Host Bus Adapter. This is literally what it is, a bus adapter (PCI/PCI-E<->SAS/SATA/FireWire/FC/whatever) which attaches to a host (PC or server). The term is used in many different contexts, nearly all of them related to storage.
The term HBA is typically used to distinguish a "plain Jane" SAS adapter from a RAID-enabled SAS adapter, although both can rightly be described as HBAs. And yes, it's used to describe Fibre Channel cards also.
The term "bus" can be misleading, since PCI Express is not a bus like PCI of old, it's a switching fabric. The old parallel SCSI used a bus topology, and serial technologies like USB and FireWire use a bus topology also. SATA uses point-to-point connections, and SAS uses a switching fabric.
Look here for more details.
The term HBA is typically used to distinguish a "plain Jane" SAS adapter from a RAID-enabled SAS adapter, although both can rightly be described as HBAs. And yes, it's used to describe Fibre Channel cards also.
The term "bus" can be misleading, since PCI Express is not a bus like PCI of old, it's a switching fabric. The old parallel SCSI used a bus topology, and serial technologies like USB and FireWire use a bus topology also. SATA uses point-to-point connections, and SAS uses a switching fabric.
Look here for more details.
Last edited:
A HBA follows the IDE philosophy that the controller is in the disk instead, and the 'controller' on the motherboard is just a host bus adapter; it doesn't control the interface itself like traditional SCSI does.
Generally, a HBA is not a FakeRAID or RAID controller, but only provides SATA/SAS connectivity without RAID functionality.
Generally, a HBA is not a FakeRAID or RAID controller, but only provides SATA/SAS connectivity without RAID functionality.
So, the board on the bottom of a SCSI drive does...what? I was under the impression that both ATA and SCSI drives used Integrated Drive Electronics ("IDE") when the technology moved away from hard cards.
Or is that not so?
I could be wrong, but this is what i have been taught:
IDE philosophy means that the actual 'interface controller' resides within the harddrive/storage unit itself, and that the 'host adapter' on motherboard/addon card only acts as dumb adapter controlled by the harddrive controller.
The old SCSI interface would be the opposite, where you get an intelligent controller interface with 'dumb' disks that do what the controller tells them.
I'm not sure where the actual difference lies; i don't know exactly how ATA or IDE or SCSI works. But i believe this stuff is just residual technical terms for an era where this change in philosophy was practiced. Right now all interface have more 'intelligence' at the storage unit side. So SAS would, unlike SCSI, also be IDE. I'm not really sure that is correct though; would love to hear from an authoritative source. But SAS is just a pimped version of SATA, with features only relevant to enterprise storage.
IDE is also used to describe two other things:
- Parallel ATA interface
- pre-UDMA transfer modes (PIO/WDMA) (<33MB/s)
So the meaning of IDE depends on the context, but appear to stem from an age where a transition was made from smart interface with dumb disks (SCSI) to dumb interface with smart disks (IDE).
IDE philosophy means that the actual 'interface controller' resides within the harddrive/storage unit itself, and that the 'host adapter' on motherboard/addon card only acts as dumb adapter controlled by the harddrive controller.
The old SCSI interface would be the opposite, where you get an intelligent controller interface with 'dumb' disks that do what the controller tells them.
I'm not sure where the actual difference lies; i don't know exactly how ATA or IDE or SCSI works. But i believe this stuff is just residual technical terms for an era where this change in philosophy was practiced. Right now all interface have more 'intelligence' at the storage unit side. So SAS would, unlike SCSI, also be IDE. I'm not really sure that is correct though; would love to hear from an authoritative source. But SAS is just a pimped version of SATA, with features only relevant to enterprise storage.
IDE is also used to describe two other things:
- Parallel ATA interface
- pre-UDMA transfer modes (PIO/WDMA) (<33MB/s)
So the meaning of IDE depends on the context, but appear to stem from an age where a transition was made from smart interface with dumb disks (SCSI) to dumb interface with smart disks (IDE).
Actually SAS is more than just a "pimped version of SATA". SAS uses the SCSI command set, while SATA uses the ATA command set. The SCSI command set is more complex, by all accounts - SAS controllers use the SATA Tunneling Protocol to send commands to SATA devices on SAS ports.
Don't worry, I also assumed that SATA used a subset of the SCSI command set, since both USB and FireWire do so, so I was quite surprised to learn otherwise. One intersting case is how exactly do SAS controllers identify SATA devices. SATA relies on physical port numbers, while SAS uses World Wide Names. However, I have a mix of newer and older SATA devices, and some have a World Wide Name, and some do not.
Since SAS is a switched fabric, I can only assume that it may fall back to using a SATA drive's serial number...
Don't worry, I also assumed that SATA used a subset of the SCSI command set, since both USB and FireWire do so, so I was quite surprised to learn otherwise. One intersting case is how exactly do SAS controllers identify SATA devices. SATA relies on physical port numbers, while SAS uses World Wide Names. However, I have a mix of newer and older SATA devices, and some have a World Wide Name, and some do not.
Since SAS is a switched fabric, I can only assume that it may fall back to using a SATA drive's serial number...
Last edited:
Megalomaniac
2[H]4U
- Joined
- Jul 27, 2004
- Messages
- 2,193
parityboy, seems like a good conversation to have. I think the virtulization group (who also post here) have a lot of experience with this. My experience has been limited and primarily high level overview. World Wide Names are the domain of enterprise systems and dataservers where the number of drives (and devices) can be staggering.
But back to the topic.
HBA is just a converter from one media to another. From PCI-e to fiber for example as parity boy said earlier).
While a RAID controller has a specific interface and actually has a logic chip that controls the flow of data to its slave devices.
But back to the topic.
HBA is just a converter from one media to another. From PCI-e to fiber for example as parity boy said earlier).
While a RAID controller has a specific interface and actually has a logic chip that controls the flow of data to its slave devices.
treadstone
Gawd
- Joined
- Jan 25, 2010
- Messages
- 567
IDE drives moved the MFM (Modified Frequency Modulation) controller that used to reside in an ISA slot on the motherboard onto the HDD hence the IDE (Integrated Drive Electronics) and with it came the 40 pin IDE connection that allowed up to two HDDs to be connected to the motherboard. Some of the MFM controller functions were moved into the motherboard chip-set and the rest was moved onto the HDD. My first HDD (a 20MB 5 1/4 MFM drive) required such an ISA MFM adapter and used a total of 2 ribbon cables per HDD, although one was shared between two HDDs. These MFM controllers (and the BIOS on the motherboard) could only handle a maximum of two HDDs. One cable carried the commands and the other was for the actual data transfer. The data ribbon cable was a dedicated connection between the HDD and the controller the command cable was shared between the two HDDs.
SCSI (the original SCSI-1) is a more intelligent approach and required a 'smart' controller and smart drives. A usual setup (e.g. single ended narrow SCSI) would involve a 50 conductor ribbon cable that up to 8 LUN (logical unit) devices could be connected to. These devices could be HDDs, scanners, printers, etc.
The controller would send commands to a LUN and the LUN's processor would be responsible to interpret the commands and handle the necessary data exchange thereafter. Hence a SCSI drive actually was intelligent.
SCSI was as any other technology enhanced over the years: SCSI-1, Fast SCSI, Fast-Wide SCSI, Ultra SCSI, Ultra Wide SCSI, Ultra2 SCSI, Ultra2 Wide SCSI, Ultra3 SCSI, Ultra-320 SCSI, Ultra-640 SCSI, etc...
SAS (Serial Attached SCSI) in essence is the continuation of that tradition just like ISA > PCI > PCI-E was (ISA and PCI= Parallel Bus to PCI-E=Serial Bus).
The same goes for SATA which is essence still is an MFM > IDE > PATA > SATA. SATA is a serial implementation of the IDE connection along with improvements...
As to the OP's question to the difference of an HBA to a RAID controller, some previous posts answered some of them already, here is my short explanation:
HBA = Host Bus Adapter meaning just what it says, its an adapter used to convert and connect the drives to via a specific BUS structure to the host system, e.g. a SATA HBA would translate the commands from the motherboard interface bus to the SATA bus to which a SATA HDD is attached to. Your motherboard has a build in HBA in the chipset to provide you with 6 or so SATA interfaces.
RAID = Redundant Array of Independent Disks, usually refers to a HBA that has a processor on board to handle the parity calculation as well as other tasks to control and manage the attached discs. There are a variety of different RAID controllers, from the simple/low cost versions that do not have a processor and off load the parity calculations to the CPU to the advanced/high end (read expensive) versions that do the parity calculation on-board, etc. Usually (but not necessarily) the more advanced RAID controllers also offer higher throughput/bandwidth.
SCSI (the original SCSI-1) is a more intelligent approach and required a 'smart' controller and smart drives. A usual setup (e.g. single ended narrow SCSI) would involve a 50 conductor ribbon cable that up to 8 LUN (logical unit) devices could be connected to. These devices could be HDDs, scanners, printers, etc.
The controller would send commands to a LUN and the LUN's processor would be responsible to interpret the commands and handle the necessary data exchange thereafter. Hence a SCSI drive actually was intelligent.
SCSI was as any other technology enhanced over the years: SCSI-1, Fast SCSI, Fast-Wide SCSI, Ultra SCSI, Ultra Wide SCSI, Ultra2 SCSI, Ultra2 Wide SCSI, Ultra3 SCSI, Ultra-320 SCSI, Ultra-640 SCSI, etc...
SAS (Serial Attached SCSI) in essence is the continuation of that tradition just like ISA > PCI > PCI-E was (ISA and PCI= Parallel Bus to PCI-E=Serial Bus).
The same goes for SATA which is essence still is an MFM > IDE > PATA > SATA. SATA is a serial implementation of the IDE connection along with improvements...
As to the OP's question to the difference of an HBA to a RAID controller, some previous posts answered some of them already, here is my short explanation:
HBA = Host Bus Adapter meaning just what it says, its an adapter used to convert and connect the drives to via a specific BUS structure to the host system, e.g. a SATA HBA would translate the commands from the motherboard interface bus to the SATA bus to which a SATA HDD is attached to. Your motherboard has a build in HBA in the chipset to provide you with 6 or so SATA interfaces.
RAID = Redundant Array of Independent Disks, usually refers to a HBA that has a processor on board to handle the parity calculation as well as other tasks to control and manage the attached discs. There are a variety of different RAID controllers, from the simple/low cost versions that do not have a processor and off load the parity calculations to the CPU to the advanced/high end (read expensive) versions that do the parity calculation on-board, etc. Usually (but not necessarily) the more advanced RAID controllers also offer higher throughput/bandwidth.
Megalomaniac
2[H]4U
- Joined
- Jul 27, 2004
- Messages
- 2,193
It sound like it is. I can't think of where it would not be. Unless there was a RAID controller that did not have some sort of SATA SAS or other connection and was more of an add on card to the Motherboard.
What about cards that offer JBOD? Your basic card that simply offers 2 SATA channels and no raid. That could still be an HBA. Or in servers you typically connect SAN enclosures via fiber channel, all that is a fiber connection goinf straight to the motherboard, no RAID there. the RAID is in the SAN.
treadstone
Gawd
- Joined
- Jan 25, 2010
- Messages
- 567
All HDD controllers are HBAs whether they are RAID or not. RAID controllers have additional functionality beyond basic HBAs. You wouldn't really use a RAID controller (aka Hardware RAID) if you just want direct access to a few drives (although most RAID controllers will allow you to do this without having to setup a RAID array). But a basic HBA will not provide RAID functionality on it's own unless you involve the systems CPU to do the parity calculation for it (Software RAID sometimes also referred to as fake RAID).
Not quite true, in that SATA does not use a bus architecture - the connections are point-to-point. In fact the term is rather legacy in nature, in the usual contexts, seeing as SAS, Fibre Channel and PCI Express don't use a bus architecture; they use a "switched fabric".
Bus = "common channel of communication". If we apply the term "bus adapter" to either end of the connection, then ironically the only "true" HBAs are:
- FireWire adapters (bus architecture)
- USB adapters (bus architecture)
- any other adapter which uses a bus at one end (ISA, PCI, PCI-X) or the other (parallel ATA, parallel SCSI, access.Bus
)That's my take on it, anyway.
sabregen
Fully [H]
- Joined
- Jun 6, 2005
- Messages
- 19,501
simple question, simple answer:
HBA means Host Bus Adapter. Literally taken, it adapts the host bus interface of PCI, VLB, ISA, EISA, PCI-X, PCI-E or another local system bus to a new type of bus. I can be IDE, SATA, SAS, Fibre Channel, iSCSI, etc. Typically (but not always) HBAs merely present physical devices that they can see. In the case of most storage HBAs, this means it presents the entire physical disk or LUN that it sees tot he Host machine
a RAID controller takes multiple physically attached target devices and creates a virtual volume out of them. The RAID controller will perform parity, sparing and other calculations as per it's specifications. This virtual volume (can be a LUN) is presented to the host. The host never sees the physical disks that the RAID controller does. There's a layer of abstraction intentionally added because the RAID controller itself is managing the physical drives that it can see. All the host knows is how big the volume is that the RAID controller is giving it, and it doesn't worry about the rest... that's the RAID controllers job.
HBA means Host Bus Adapter. Literally taken, it adapts the host bus interface of PCI, VLB, ISA, EISA, PCI-X, PCI-E or another local system bus to a new type of bus. I can be IDE, SATA, SAS, Fibre Channel, iSCSI, etc. Typically (but not always) HBAs merely present physical devices that they can see. In the case of most storage HBAs, this means it presents the entire physical disk or LUN that it sees tot he Host machine
a RAID controller takes multiple physically attached target devices and creates a virtual volume out of them. The RAID controller will perform parity, sparing and other calculations as per it's specifications. This virtual volume (can be a LUN) is presented to the host. The host never sees the physical disks that the RAID controller does. There's a layer of abstraction intentionally added because the RAID controller itself is managing the physical drives that it can see. All the host knows is how big the volume is that the RAID controller is giving it, and it doesn't worry about the rest... that's the RAID controllers job.
Do you mean like the Arecas, which can be put in JBOD mode, so that each disk is fully visible to the OS?
no that is soft raid and not bootable. i am speaking of the LSI cards with IR (integrated Raid) they have a strong enough ROC to boot your computer, then the driver handles the calculation through your CPU once the OS is loaded. gives you soft raid speeds with hard raid bootability.
Techno Wizard
n00b
- Joined
- May 7, 2017
- Messages
- 1
Another, simpler way to think of it is like this:
HBA is a dumb adapter while a RAID controller is a smart device.
HBA (Host Bus Adapter) is just an adapter. It allows you to connect drives to the host device's data bus. See how that works? Host = the Computer to which the drives are being attached to and the card is installed into. Bus is short for DATA Bus. These days, that is usually PCIe which allows devices to transfer data to and from the DMI. The DMI is essentially a data bridge between the CPU, RAM, PCIe, (and rarely, old style PCI or even EISA/ISA. Before anyone argues with this: If you search hard enough, you can find specialty boards that still have PCI and/or ISA/EISA slots. Usually only one. These were/are made for those circumstances when a customer, usually in the manufacturing industry, has an old proprietary card for a piece of equipment that would be extremely expensive to replace and there are no newer controllers made for it. This is the same reasoning for still including the old style, 9 or 25 pin serial ports on some motherboards or laptops.) HBA either has no or very little processing power on it's own. Those HBA devices that allow RAID, uses the CPU for all raid calculations, which make them somewhat limited in functionality and often unreliable as a RAID controller, in addition they are using up precious CPU cycles to handle the RAID functions. They could be called "A poor man's RAID controller."
A RAID controller (key word here is 'controller') does much more than just act as an adapter for the drives to connect to. A RAID has it's own processor, it's own BIOS, and it's memory (used as a cache for reads and writes.) It does not rely on the CPU for any of it's functions. It receives the requests for data to be retrieved or it receives the data to be written along with the details of which volume it is to be written to or read from. It controls all of the hardware and presents to the OS a list of it's volumes, as though each of those volumes were an independent drive, even though, in the background, they may consist of many drives configured for varying levels of data redundancy (also referred to as data safety) and/or performance. RAID 0 is sort of a misnomer: RAID = Redundant Arrays of Independent Drives (or Disks, depending on who you ask. I prefer the word Drives, because not all storage medium are disks. SSD anyone?) RAID 0 does not provide any redundancy of data. It merely stripes the data across 2 or more drives for the sole purpose of increasing the rates which the data can be written and/or read. It is my personal belief that this is the reason it is designated as RAID level 0, as it provides 0 redundancy. The better the controller, the more it is capable of. I personally use an Adaptec (now Microsemi) 72405 RAID controller. It provides 24 internal ports via 6 SFF-8643 connectors. There are 6 channels, each of which provide 4 ports via a fan-out cable. One may attach either a SAS or a SATA drive to each port.
In the old days, drives had to be low level formatted (this is different than what occurs today when you "format" a hard drive.) When you performed a low level format, you did several things, You initialized the drive, you mapped out the bad sectors and the sector map was stored on the controller and you set the sector write to sectors skipped ratio ( I have forgotten the actual term for that ratio.) The drives did not have the ability to write data contiguously from physical sector to physical sector. After writing in one sector, the drives needed a short amount of time prepare for the next sector's worth of data (512 bytes.) A 3:1 ratio was not uncommon, which meant the drive would write one sector then skip 3 sectors before writing the next. If this ratio was to low, then the drive would not be ready and would have to wait for the platter to complete it's rotation for the sector to come into position again. All of this information was stored on the controller. Then a new way of doing this was introduced. IDE or Integrated Drive Electronics. The drive was low level formatted, mapped and optimized at the factory. All of the data was stored on the integrated controller. End users no longer needed to know all about the inner workings of the technology in order to make the best use of it. You had IDE for the average user or less critical users and then you had SCSI for those that needed greater levels of performance and capacity
Today, we still have fibre channel, but it is becoming less and less of an advantage and some argue that it is not an advantage at all. Instead, we have SATA and SAS. What are the differences? Primarily, performance. SAS drives tend to be faster than SATA, but you often sacrifice capacity for that performance and pay a premium for it as well. When I was setting up my system, I weighed the advantages and disadvantages of both. I had to break the old paradigm of "SCSI is better!!!" Many are still stuck in that paradigm. The paradigm has shifted. The new drives all have integrated drive electronics now, even though they are not called IDE. That is to say, the sector mapping is stored in the integrated electronics of all the drives. SATA and SAS use the same interface and RAID controllers automatically determine which drive type is attached to each port and they can be mixed. With innovation of the serial interface for drives, they have essentially brought SCSI and IDE closer together in function and performance, though there is still a difference. Personally, I have found that I can get just as much, if not more performance out of 2 striped SATA drives as I would out of a single SAS drive, plus I have more storage capacity and didn't waste money on the SAS premium. That is reasonable thinking for my circumstances. But, there are situations where you need the performance of SAS drives combined together into a complex RAID configuration that will provide both data safety and a high performance. Such situations are generally referred to as 'enterprise' environments. Consider a company that is designing and building the next generation of fighters for the Air Force, Marines and/or Navy (though marines are actually a part of the department of the navy.) The engineers and technicians involved in the design process and then the simulation process, need the speed as well as capacity. For them SAS would make more sense. SAS would provide the increased performance and their budget would allow for the capacity. For me, the most demanding tasks my system performs, are for games and I store a lot of video for editing. But I'm not running a system that uses 24 XEON processors and exabytes of data storage that needs to transfer at sustained rates in excess of a terabyte per second.
As to the question of how are the drives addressed, well, it's not quite the same way as it is in the older SCSI system. Some of what I am about to say is a little bit of guess work and some thing I know to be fact. Let's get the factual stated first. When I look at the drive configurations on my controller, there is a hierarchy to it. At the top is the controller (if I had more than one, the could be directly linked and volumes could be spanned across multiple controllers, which is another advantage to actual RAID controllers over HBA,) Under each controller is a tree of channels, the channels break down into ports and under the port is the drive detail ( only 1 drive per port. ) When you configure a multi drive volume (in my case a RAID 5 volume) the controller reserves some space on the drive to indicated what position in the array the drive occupies. This means that if I removed all of the drives and then replaced them all in a different order, the volume would still function. An alert would be generated to let me know that the array had been tampered with, but it would still be functional with no data loss or rebuilding necessary. This referred to as a roaming drive profile. If you did that in the old days, you would break the volume. (This is another advantage to RAID controllers over HBAs.) Now, with all this said and much exploration of the controller and the drives attached, the only drive specific address I could find was given to the drives in the RAID 5 volume, which I assume is how the drive are able to roam. Those drives which were installed as standalone drives, had no discernible address. The closest thing to an address I could find was "Controller #, channel #, Port #" and nothing else that even came close, except the electronic serial numbers. Now, the guessing part. I believe that with SAS/SATA RAID controllers, the addressing is actually the controller #, Channel #, Port #. If the controller had reserved space on the standalone drives as well as the drives installed as part of the RAID volume, I would have believed the address was actually written into the first sector of the drive. But since it does not reserve that space, I assume the addressing is handled by where the drive is attached to the controller. In other words, it is the port that has an address, not the drive. that would also be the logical way deal with the issue of both SCSI and non-SCSI being able to use the same ports/connectors, able to mixed on a single controller without issue and not require any additional connection to handle addressing. It would also be in line with the "plug 'n' play" mindset.
HBA is a dumb adapter while a RAID controller is a smart device.
HBA (Host Bus Adapter) is just an adapter. It allows you to connect drives to the host device's data bus. See how that works? Host = the Computer to which the drives are being attached to and the card is installed into. Bus is short for DATA Bus. These days, that is usually PCIe which allows devices to transfer data to and from the DMI. The DMI is essentially a data bridge between the CPU, RAM, PCIe, (and rarely, old style PCI or even EISA/ISA. Before anyone argues with this: If you search hard enough, you can find specialty boards that still have PCI and/or ISA/EISA slots. Usually only one. These were/are made for those circumstances when a customer, usually in the manufacturing industry, has an old proprietary card for a piece of equipment that would be extremely expensive to replace and there are no newer controllers made for it. This is the same reasoning for still including the old style, 9 or 25 pin serial ports on some motherboards or laptops.) HBA either has no or very little processing power on it's own. Those HBA devices that allow RAID, uses the CPU for all raid calculations, which make them somewhat limited in functionality and often unreliable as a RAID controller, in addition they are using up precious CPU cycles to handle the RAID functions. They could be called "A poor man's RAID controller."
A RAID controller (key word here is 'controller') does much more than just act as an adapter for the drives to connect to. A RAID has it's own processor, it's own BIOS, and it's memory (used as a cache for reads and writes.) It does not rely on the CPU for any of it's functions. It receives the requests for data to be retrieved or it receives the data to be written along with the details of which volume it is to be written to or read from. It controls all of the hardware and presents to the OS a list of it's volumes, as though each of those volumes were an independent drive, even though, in the background, they may consist of many drives configured for varying levels of data redundancy (also referred to as data safety) and/or performance. RAID 0 is sort of a misnomer: RAID = Redundant Arrays of Independent Drives (or Disks, depending on who you ask. I prefer the word Drives, because not all storage medium are disks. SSD anyone?) RAID 0 does not provide any redundancy of data. It merely stripes the data across 2 or more drives for the sole purpose of increasing the rates which the data can be written and/or read. It is my personal belief that this is the reason it is designated as RAID level 0, as it provides 0 redundancy. The better the controller, the more it is capable of. I personally use an Adaptec (now Microsemi) 72405 RAID controller. It provides 24 internal ports via 6 SFF-8643 connectors. There are 6 channels, each of which provide 4 ports via a fan-out cable. One may attach either a SAS or a SATA drive to each port.
In the old days, drives had to be low level formatted (this is different than what occurs today when you "format" a hard drive.) When you performed a low level format, you did several things, You initialized the drive, you mapped out the bad sectors and the sector map was stored on the controller and you set the sector write to sectors skipped ratio ( I have forgotten the actual term for that ratio.) The drives did not have the ability to write data contiguously from physical sector to physical sector. After writing in one sector, the drives needed a short amount of time prepare for the next sector's worth of data (512 bytes.) A 3:1 ratio was not uncommon, which meant the drive would write one sector then skip 3 sectors before writing the next. If this ratio was to low, then the drive would not be ready and would have to wait for the platter to complete it's rotation for the sector to come into position again. All of this information was stored on the controller. Then a new way of doing this was introduced. IDE or Integrated Drive Electronics. The drive was low level formatted, mapped and optimized at the factory. All of the data was stored on the integrated controller. End users no longer needed to know all about the inner workings of the technology in order to make the best use of it. You had IDE for the average user or less critical users and then you had SCSI for those that needed greater levels of performance and capacity
Today, we still have fibre channel, but it is becoming less and less of an advantage and some argue that it is not an advantage at all. Instead, we have SATA and SAS. What are the differences? Primarily, performance. SAS drives tend to be faster than SATA, but you often sacrifice capacity for that performance and pay a premium for it as well. When I was setting up my system, I weighed the advantages and disadvantages of both. I had to break the old paradigm of "SCSI is better!!!" Many are still stuck in that paradigm. The paradigm has shifted. The new drives all have integrated drive electronics now, even though they are not called IDE. That is to say, the sector mapping is stored in the integrated electronics of all the drives. SATA and SAS use the same interface and RAID controllers automatically determine which drive type is attached to each port and they can be mixed. With innovation of the serial interface for drives, they have essentially brought SCSI and IDE closer together in function and performance, though there is still a difference. Personally, I have found that I can get just as much, if not more performance out of 2 striped SATA drives as I would out of a single SAS drive, plus I have more storage capacity and didn't waste money on the SAS premium. That is reasonable thinking for my circumstances. But, there are situations where you need the performance of SAS drives combined together into a complex RAID configuration that will provide both data safety and a high performance. Such situations are generally referred to as 'enterprise' environments. Consider a company that is designing and building the next generation of fighters for the Air Force, Marines and/or Navy (though marines are actually a part of the department of the navy.) The engineers and technicians involved in the design process and then the simulation process, need the speed as well as capacity. For them SAS would make more sense. SAS would provide the increased performance and their budget would allow for the capacity. For me, the most demanding tasks my system performs, are for games and I store a lot of video for editing. But I'm not running a system that uses 24 XEON processors and exabytes of data storage that needs to transfer at sustained rates in excess of a terabyte per second.
As to the question of how are the drives addressed, well, it's not quite the same way as it is in the older SCSI system. Some of what I am about to say is a little bit of guess work and some thing I know to be fact. Let's get the factual stated first. When I look at the drive configurations on my controller, there is a hierarchy to it. At the top is the controller (if I had more than one, the could be directly linked and volumes could be spanned across multiple controllers, which is another advantage to actual RAID controllers over HBA,) Under each controller is a tree of channels, the channels break down into ports and under the port is the drive detail ( only 1 drive per port. ) When you configure a multi drive volume (in my case a RAID 5 volume) the controller reserves some space on the drive to indicated what position in the array the drive occupies. This means that if I removed all of the drives and then replaced them all in a different order, the volume would still function. An alert would be generated to let me know that the array had been tampered with, but it would still be functional with no data loss or rebuilding necessary. This referred to as a roaming drive profile. If you did that in the old days, you would break the volume. (This is another advantage to RAID controllers over HBAs.) Now, with all this said and much exploration of the controller and the drives attached, the only drive specific address I could find was given to the drives in the RAID 5 volume, which I assume is how the drive are able to roam. Those drives which were installed as standalone drives, had no discernible address. The closest thing to an address I could find was "Controller #, channel #, Port #" and nothing else that even came close, except the electronic serial numbers. Now, the guessing part. I believe that with SAS/SATA RAID controllers, the addressing is actually the controller #, Channel #, Port #. If the controller had reserved space on the standalone drives as well as the drives installed as part of the RAID volume, I would have believed the address was actually written into the first sector of the drive. But since it does not reserve that space, I assume the addressing is handled by where the drive is attached to the controller. In other words, it is the port that has an address, not the drive. that would also be the logical way deal with the issue of both SCSI and non-SCSI being able to use the same ports/connectors, able to mixed on a single controller without issue and not require any additional connection to handle addressing. It would also be in line with the "plug 'n' play" mindset.