There Is No “N” in LUN

Tech Blog

There Is No “N” in LUN

There Is No “N” in LUN

Dec 16, 2015

This article serves as an introduction to a series of posts we’ll be adding regarding some groundbreaking features that will soon be included in our data migration product, DMS. Before we added those posts, we felt it was necessary to clarify some terminology before moving the discussion forward.

The term “LUN” is ubiquitous in the fibre channel world. If you look it up, the first Wikipedia result notes that LUN stands for “logical unit number.” But storage folks might also bump up against the term “lun” (lower case) and “LU” as well. While we may guess “LU” may represent “Logical Unit,” what then is “lun?” Is it the same as “LUN” (upper case)? And what does each of these terms/acronyms really represent?

It can be downright confusing, especially for neophytes just entering the esoteric fibre channel universe. Few know the precise traditional definitions, and even fewer are aware of the etymology. Understanding the origin and history of these terms may help demystify the jargon.

The Short Answer, LUN is Not lun

LUN refers to a logical disk in a SAN environment. This disk is technically a logical unit, or LU – a more accurate term still found in some literature. While a LUN can also be an LU, not all LUs are LUNs. LUs may be logical disks, tape drives, or even tape libraries which are connected to a fibre channel SAN, but only logical disks are called LUNs.

“LUN” is actually a solecism almost created by accident, because of its confusion with “lun,” which actually refers to “logical unit number.” Traditionally, storage engineers separated their LUNs from their luns, but over time the distinction has blurred.

In a fibre channel SAN, most of the time administrators are dealing with logical disks. Since “LU” is not exactly an easy to use acronym (is it “Lou?” or is it “El Yew?”), the term LUN was adopted as a nickname for a logical disk almost by mistake, and the label eventually went mainstream. Contrary to most information on the web, not only does LUN not stand for logical unit number, but just like other LUs, a LUN doesn’t even have a definitive lun.

Before we talk about why LUs and LUNs don’t have luns by nature, here’s a hypothetical that reveals why we even bring this up: If a systems administrator is given a disk for a database server, one might say the sysadmin has been provisioned a LUN (logical disk). If the sysadmin then asks the storage admin what logical unit number is the LUN, is he asking what LUN is the LUN?

A logical unit number – or lun – is only assigned to an LU when it is provisioned to a specific host (via its HBAs), and that assignment is only meaningful for that host at that time. For example, a host may display one of its provisioned LUs as lun 0, yet if the same LU is provisioned to another host, that host may show the very same LU has been given a lun of 3. Therefore, a lun is not an independent and persistent identity of an LU. In short, a LUN is not a lun. There is no “N” in LUN.

An LU is only uniquely identified by what we loosely call a GUID, for storage that is compliant to industry standards. This is especially important for logical disks, or LUNs. It is important to differentiate between LUN and lun in fibre channel, or even in iSCSI when working with SAN, especially in multipath configurations.

To more fully understand the lun, and how it is related to LUN, you may have to read “the rest of the (longer) story.”

The SCSI Origin of lun

The term lun actually has its root in SCSI, or “Small Computer System Interface.” SCSI is a standard that was created for general peripheral component connectivity for computers. Today, it is applied almost exclusively to storage. The SCSI standard covers the complete connectivity spectrum – from mechanical, to electrical, to command protocol, and logical organization.

In ancient times, external storage disks were connected to the computer by a SCSI cable, or bus, which comprised multiple twisted-pair wires. Some of these wires were used for addressing, some for data, and some carried power. SCSI cables could connect to multiple entities by “daisy-chaining,” where one device connected to another device, which connected to yet another device, forming a “chain.” In the beginning, SCSI could only chain up to 7 entities, but this was later expanded to more.

In a SCSI bus, the adapter from the computer is usually referred to as the initiator, and the other entities are referred to as targets. Therefore the configuration contains one initiator with potentially multiple targets (except in a cluster configuration). The terms “SCSI initiator” and “SCSI target” describe the client and server relationship in this SCSI paradigm. All the entities in this bus are assigned with an ID. The initiator is given ID 7, and the targets are uniquely assigned the other 7 IDs. They are referred to as the initiator ID and target IDs, and are actually hardware implemented. A dipswitch (a switch with “bits” set to different digital patterns) is used to set the ID for each entity in the bus. This is how the initiator selects a target for access.

The target entity is actually designed to be a controller. This means a target can be a complex entity that houses multiple logical units. For example, a storage subsystem is a target containing multiple disks. Each of these disks can be further specified by a logical unit number, or “lun.” This allows the initiator to directly access the individual disks by specifying the target ID and the logical unit number. This is how we obtain the term “lun.”

Fibre Channel SAN & SCSI

How does fibre channel LUN come in and tangle up with the notion of lun? We will continue to expound on this topic in part 2 of this article.

About the Author:

About the Author:

Wai Lam

Before joining Cirrus Data Solutions, Wai co-founded FalconStor Software in 2000, where he served as CTO and VP of Engineering. Wai was the chief architect, holding 18 of the 21 FalconStor patents. His inventions and innovations include many of industry’s “firsts,” in areas of advanced storage virtualization, data protection, and disaster recovery. Wai received a MSEE from UCLA, 1984, and BSEE from SUNY Stony Brook, 1982. He was honored with the Distinguished Alumni Award from Stony Brook in 2008.

Before joining Cirrus Data Solutions, Wai co-founded FalconStor Software in 2000, where he served as CTO and VP of Engineering. Wai was the chief architect, holding 18 of the 21 FalconStor patents. His inventions and innovations include many of industry’s “firsts,” in areas of advanced storage virtualization, data protection, and disaster recovery. Wai received a MSEE from UCLA, 1984, and BSEE from SUNY Stony Brook, 1982. He was honored with the Distinguished Alumni Award from Stony Brook in 2008.

Before joining Cirrus Data Solutions, Wai co-founded FalconStor Software in 2000, where he served as CTO and VP of Engineering. Wai was the chief architect, holding 18 of the 21 FalconStor patents. His inventions and innovations include many of industry’s “firsts,” in areas of advanced storage virtualization, data protection, and disaster recovery. Wai received a MSEE from UCLA, 1984, and BSEE from SUNY Stony Brook, 1982. He was honored with the Distinguished Alumni Award from Stony Brook in 2008.