Posts Tagged ‘Glossary’

Tagged Command Queuing

Tagged Command Queuing (TCQ) is a function that allows multiple commands to be sent to a SCSI disk drive (includes Fibre Channel drives), and now some SATA drives.  The “twist” when you do command queuing on SATA drives, is that they don’t used the same name – they call it Native Command Queuing (NCQ).  I don’t think this is a good name because it might imply that command queuing is or was native in the SATA world.  But I suppose the name was picked more for sales people and not technically oriented geeks like me (off soapbox now).

Why Command Queuing?

So you may be asking the question: “Why do we do queuing?”  There are really a few main reasons which are:

Speed, efficiency, less stress on the physical parts, which results in longer device lifetime.

How Command Queuing Works

I will try to keep this as simple as possible by using an analogy or two.  Try to think of a disk drive as an elevator, and the sectors (or blocks) where it stores the data are labeled from zero (0) to some maximum number (let’s say 100 to keep it easy). Each command that accesses data will include a “Where” field, which is normally called the Logical Block Address (LBA).  Think of that as the “floor number” of this elevator.

Now imagine that the disk drive is the elevator sitting at Floor 0 (ground floor) and the operating system sends 5 commands to the drive, that all go to different floors and in a different order.  For example

  • Command 01 moves data to floor 90 (LBA=90)
  • Command 02 moves data from floor 10 (LBA=10)
  • Command 03 moves data to floor 80 (LBA=80)
  • Command 04 moves data from floor 20 (LBA=20)
  • Command 05 moves data to floor 70 (LBA=70)

elevator iconThe doors close and the elevator starts to do its thing (move the commands and data).  Now if the elevator operator (the device firmware) had to do each of these commands in the order they were received, then that would take quite a bit of time and the elevator would have to move quite a distance between each command (first to floor 90, then to floor 10,  then back to 80, and so on).  As you can imagine, that would also add quite a bit of physical movement and is not very efficient.

But now think about how a real elevator works.  These same five commands jump on the elevator at the ground floor and the doors close.  What happens next? The elevator doesn’t care about the sequence the buttons for each floor were pressed, it just cares about which floor is closest to its current location, and what direction it is going.  This simple “elevator algorithm” would result in the following command execution sequence:

  • Command 02 moves data from floor 10 (LBA=10)
  • Command 04 moves data from floor 20 (LBA=20)
  • Command 05 moves data to floor 70 (LBA=70)
  • Command 03 moves data to floor 80 (LBA=80)
  • Command 01 moves data to floor 90 (LBA=90)

Note that the elevator only moved between floors (moved the head on the drive) in the most efficient manor, and did not bounce back and forth (seek) multiple times.  The result is that the overall processing time will be reduced and there is less physical movement when compared to doing the commands in the original order that they were given.

So its all about speed and efficiency.  If you have any questions, leave a comment.

Incoming search terms for the article:

1 comment - What do you think?  Posted by Greg - June 15, 2010 at 7:10 AM

Categories: Glossary   Tags:

Bits Bytes and Blocks

When discussing Storage Networking, or getting into the “nuts and bolts” of commands and moving data around, the topic of Bits, Bytes, and Blocks almost always seems to come up.  It usually starts with a question like “where can I find the bit that turns on (or off) a particular function.”

For example, there is a bit called “IMMED” (Immediate) in several SCSI commands (CDBs) that tells the device to send back Status immediately.  This is not really true, if you read the details about that particular bit, but the important part is where will you find this bit and how would you identify it in a precise manor.  That is where the bits and bytes come in.

Bits and Bytes

The example above shows that this particular bit is Bit zero (0) of Byte one (1), in this particular command.  Where the confusion comes in is usually based on what a person has worked with in the past and what they are used to.

In some environments, people will often start with bit 0 on the far left and move up as they move to the right.  But since most of the storage industry started with bit 7 on the left of each byte, and count down as they move to the right, this is the way it is displayed and labeled in the SCSI Standards.

Also note that in SCSI land (the land of storage) when we start counting bytes, we start with zero (0) and count up from there (even if the bytes are shown going down the page).  That is why this 6-byte command (or 6-byte CDB) starts with byte 0 and goes to by 5 – a total of six bytes.  The key for most people is to be flexible, and get to know the system that you are working with.

Blocks

That brings us to Blocks, and the big question of “How big is a Block?”  The real answer to that question is … It depends!  What is depends on is the device type that you are talking to.  Since a large amount of people in the storage industry deal with disk drives, the “typical” answer is – 512 bytes.  I say “typical” because I have worked with systems that have larger block sizes, such as 520 or 528 byte blocks.  These are usually hard drives that are installed in special RAID arrays and have been formatted for that system.

When you talk with different device types, the block size may be different. For example, many of the optical media devices I have worked with use a 2K byte block size.  Again, you have to be flexible and have the ability to find out how the device you are talking to is used most of the time.

If you have any questions, just leave a comment here.

Incoming search terms for the article:

Be the first to comment - What do you think?  Posted by Greg - June 8, 2010 at 7:07 AM

Categories: Glossary   Tags:

Fibre Channel

Fibre Channel – often referred to as FC, is and has been the main infrastructure and protocol used in the storage networking industry since the mid 1990s.  Its high speed (multi-gigabit) data rate has been enhanced over the years, allowing up to about 8 gigabits per second today, and twice that rate in the near future.

Not Necessarily Fiber-Optics

One of the biggest misconceptions is that Fibre Channel exclusively used fiber optic cables, or links.  While it is true that long distance runs will be carried over optical links, many FC disk enclosures carry the signals over copper cables, or traces on a backplane.  Obviously there has to be somewhere that the conversion takes place between optics and copper, and a very common component that does this is the GBIC (GigaBit Interface Converter).

Topologies

There are three basic topologies used with Fibre Channel.  These are point-to-point, Arbitrated Loop, and Switched Fabric.

Point-to-point is the simplest, and is exactly what it sound like, where two devices, or nodes, are connected directly together.

Arbitrated Loop is when a series of device are connected in a ring, or loop.  This allows multiple devices to be connected and available for use.  This is a very common configuration for a JBOD (Just a Bunch of Disks) type enclosure.  A limitation of this configuration is that only two node can use the loop at any given time.

Switched Fabric is the most common topology used in enterprise class storage system.  This means that a Fibre Channel Switch will be used to connect multiple devices and adds the capability of having multiple communications occurring at that same time.  The more ports you have on the switch, the more simultaneous communications you can have.  Of course this increases the cost and complexity of the system, but you don’t get high speed simultaneous data flow for free.

There is much more to Fibre Channel than what will fit in a single glossary post, but I will try to add more in the future.  Please let a comment if you have specific questions.

Incoming search terms for the article:

Be the first to comment - What do you think?  Posted by Greg - May 17, 2010 at 12:36 PM

Categories: Glossary   Tags:

Next Page »