What is an unaligned I/O?

What is an unaligned I/O?

KB ID: 3011193  Version: 16.0  Published date: 04/02/2014 

 

Answer

To explain an I/O alignment, is it first necessary to explain how LUNs are used as storage devices by the host operating system. LUNs and hard disks provide storage as blocks, where a block is an addressable unit of storage measured in bytes. The traditional block size advertised by hard disks is 512 bytes. New hard disks such as advanced format drives and NetApp LUNs use a larger block size to store the data while continuing to advertise smaller 512 byte blocks to the host for compatibility purposes. The advertised blocks are referred to as logical blocks while the underlying storage block is referred to as a physical block. The NetApp LUN stores data in 4kB physical blocks which yields eight 512 byte logical blocks per physical block.

 

The host operating system might begin a Read or Write (I/O) operation at any logical block. However, when the I/O begins at a logical block that is not at the start of a physical block, then the I/O is said to be misaligned.

I/Os are aligned only when they begin at a logical block that is the first logical block in a physical block. That is to say, the I/O aligns to the physical block boundary.

Identifying I/O Alignment for LUNs 

Data ONTAP contains a heuristic detection mechanism that automatically identifies misaligned I/O to LUNs. The heuristic checks the work by observing the position within a physical block where the I/O begins, as well as the I/O length. The heuristic’s output will be one of the following: indeterminate, aligned, misaligned or partial writes. The indeterminate state is only applied when the LUN has not received enough I/O to decide on the alignment. For the LUN that is in constant use, this state will be short lived and the heuristic will identify one of the other states. The partial writes state identifies LUNs that receive the majority of I/Os smaller than 4kB. Typically, this state will apply to LUNs used by database transaction or redo logs. This state does not indicate an issue; it is used to separate this situation from the misaligned state. As workloads change, it might be necessary to reset the alignment heuristics by running the lun stats –z command. 

The following example shows a LUN where the heuristics have identified the I/O as misaligned. The Read and Write alignment histograms record the percentage of I/O that begins at each of the eight positions within a physical block. This hypothetical example shows that 100% of read and write I/Os are starting in the eighth position, also known as a histogram bucket. 

*> lun alignment show /vol/luns/my_lun

Multiprotocol type: linux

Alignment: misaligned

Write alignment histogram percentage: 0, 0, 0, 0, 0, 0, 0, 100

Read alignment histogram percentage: 0, 0, 0, 0, 0, 0, 0, 100

Partial writes percentage: 0

     Partial reads percentage: 0 

The next example shows a LUN where the heuristics have identified the I/Os as aligned. The Read and Write alignment histograms show 100% of the I/O’s are beginning in the first position which is align to the physical block boundary. 

*> lun alignment show /vol/luns/my_lun

     Multiprotocol type: windows

     Alignment: aligned

     Write alignment histogram percentage: 100, 0, 0, 0, 0, 0, 0, 0

     Read alignment histogram percentage: 100, 0, 0, 0, 0, 0, 0, 0

     Partial writes percentage: 0

     Partial reads percentage: 0 

The final example shows the partial writes state on a LUN. Here you will see some amount of the percentage of total I/O being accounted for in the Partial writes and Partial reads fields. The exact amount of partial writes and reads are dependent on the application performing the I/O and the nature of the workload on that application. The percentages might not add up to 100, this is expected and does not indicate an issue with the heuristic calculation. 

*> lun alignment show /vol/luns/my_lun

     Multiprotocol type: linux

     Alignment: partial-writes

     Write alignment histogram percentage: 0, 0, 0, 0, 0, 0, 0, 0

     Read alignment histogram percentage: 1, 6, 1, 3, 0, 4, 6, 6

     Partial writes percentage: 0

     Partial reads percentage: 68 

Contributing Factors to I/O Alignment for LUNs 

The way a host operating system uses a LUN varies greatly by the OS type, partition scheme, file system and application. For the majority of situations where I/O is misaligned, the key contributing factor is the partition scheme employed by the host OS and will also be influenced by the file system or an application such as a database. As a rule of thumb, you should choose the Data ONTAP LUN  OS type that most closely matches the host operating system to the  OS type. The following table provides additional guidance. In some circumstances custom partition tables might be required. Some Data ONTAP LUN  OS types use an offset known as a prefix to enable the default partition scheme used by the associated host operating system to be aligned. For LUNs with a prefix value greater than 0, a custom partition might create misaligned I/O. 

Database Log LUNs

LUNs that are used as the log location for a Database application, such as Oracle (redo log) or Microsoft's SQL Server (transaction log), can see a very random distribution of unaligned write I/O across the alignment histogram. This is normal and expected behavior for this type of I/O. That said, in cases where we know the LUN is being used as a DB log location, and we've confirmed that correct lun type, and offset are being used, no further corrective actions are possible or necessary.

LUN ostype	Prefix (bytes)	Prefix (sectors)	Operating System
windows	32,256	63	Windows 2000, 2003 (MBR format)
windows_gpt	17,408	34	Windows 2003 (GPT format)
windows_2008	0	0	Windows 2008 and later
hyper_v	0	0	Windows 2008 Hyper-V abd later
linux	0	0	All Linux distributions *
xen	0	0	Citrix XenServer
vmware	0	0	VMware ESX*
solaris	1MB	2048	Solaris *
solaris_efi	17,408	34	Solaris *
hpux	0	0	HP-UX
aix	0	0	AIX

* Indicates additional consideration might be required, see the information below. 

Additional Considerations for Linux 

Linux distributions offer a wide variety of ways to use a LUN including as raw devices for databases, volume managers and file systems. It is not necessary to create partitions on a LUN when used as a raw device or when used as a physical volume in a volume manager. If the LUN will be used without a volume manager, then a good practice to follow is to partition the LUN such that it has one partition that begins at an aligned offset, that is a sector that is an even multiple of eight logical blocks. For details on creating aligned partitions of Linux, see article 1010717: How to create aligned partitions in Linux for use with NetApp LUNs, VMDKs, VHDs and other virtual disk containers. 

Additional Considerations for VMware ESX/ESXi

Typically, the unaligned I/O seen on a type VMware LUN will be due to VMDK alignment issues introduced by the guest OS partitioning of its disk. Refer TR-3747 as specified in the section, I/O Alignment for Files, below. 

Additional Considerations for Solaris 

Solaris offers a wide variety of ways to use a LUN including many different file systems and volume managers. No special partitioning is necessary for Solaris, however it is important to know when to use either the solaris or solaris_efi LUN ostype. You should use the solaris_efi LUN ostype only for LUNs larger than 990GB that will be formatted with UFS. The solaris_efi LUN ostype is used to offset the default starting location of the first partition after the EFI disk label, which is sector 34. You should use the solaris LUN ostype for all other configurations include SVM, VxVM, ZFS and UFS smaller than 990GB. On Solaris versions 10u8 and newer, where ZFS is being used, a LUN ostype of solaris should be used along with adding physical-block-size:4096 to the host's sd.conf file (ssd.conf for Solaris x86).

I/O Alignment for Files 

I/O alignment for files works exactly like it does for LUNs. Typically misaligned I/O for files occurs with those files used as virtual disks or disk images accessed via a NAS protocol.  It is therefore important that virtual disks have their partitions aligned to file block boundaries for optimal I/O throughput. For a detailed discussion of aligning virtual disks for optimal performance, see TR-3747, Best Practices for File System Alignment in Virtual Environments, . 

Related Links:

• TR-3747: Best Practices for File System Alignment in Virtual Environments ()
• 1010717: How to create aligned partitions in Linux for use with NetApp LUNs, VMDKs, VHDs and other virtual disk containers
• 1010803: How to diagnose misaligned I/O on Windows hosts