Dell Unity: Linux LUN format warning-alignment is offset by 512 bytes. This may result in poor performance
Summary: Dell Unity: Linux LUN format warning-alignment is offset by 512 bytes. This may result in poor performance.
Symptoms
This issue is because Dell Unity advertises SPC-4 support, which results in changes in Linux SCSI behavior compared to a Linux attach to VNX2/VNX family arrays.
Two things impact makefs performance:
- Linux now issue unmap commands to a thin Dell Unity LUN.
- Linux uses data returned in an Inquiry Vital Product Data Page 0xB2 to decide how to align a file system, and the data returned by the array results in a mis-aligned file system.
Linux LUN format warning-alignment is offset by 512 bytes. This may result in poor performance.
# mkfs.ext3 /dev/mapper/mpathd1 mke2fs 1.42.9 (28-Dec-2013) /dev/mapper/mpathd1 alignment is offset by 512 bytes. This may result in very poor performance, (re)-partitioning suggested. <<<<<<<<<<< Disk /dev/mapper/VGsdb-LVsdb: 29.9 TiB, 32875361599488 bytes, 64209690624 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 8192 bytes / 33553920 bytes Alignment offset: 512 bytes
Cause
Linux fdisk uses the optimal transfer size found in an Inquiry Vital Data Page 0xB0 as the start sector when creating a partition on a LUN with no partitions. Since this optimal transfer size is 65535, mkfs will subsequently (and correctly) claim that the file system is misaligned.
Changing the optimal transfer size in an Inq VPD page 0xB0 will be done in a future Dell Unity update.
Resolution
As a workaround, the customer can use 2048 (decimal) as the starting SECTOR for fdisk. "mkfs" then build a properly aligned file system. Note that Linux partition/file system utilities have various switches/options for creating partitions and file system. They can use sectors or cylinders as units. We want them to use SECTORS as units of measurement with their utilities.
If creating two or more partitions on a LUN, the subsequent partitions should be created with a starting SECTOR as a multiple of 2048.
If you use "fdisk -c," instead you have to specify to start at 65536 (system gives default value of 65535) "-c" is the dos compatibility mode and according to the linux man page, this option should be used.
Also if you do not use the "-c" option, you get the following.
[root@localhost nasadmin]# fdisk -u /dev/sdi WARNING: DOS-compatible mode is deprecated. It's strongly recommended to switch off the mode (command 'c').
As a workaround for the "fdisk -c" to use 65536 as a starting sector. That produces aligned file systems.
Additional Information
If "-c" option is not used with the fdisk command:
As a workaround, the customer can use 2048 (decimal) as the starting SECTOR for fdisk.
"mkfs" then build a properly aligned file system. Note that Linux partition/file system utilities have various switches/options for creating partitions and file system.
They can use sectors or cylinders as units. We want them to use SECTORS as units of measurement with their utilities.
Partition number (1-4): 1
First sector (1-167772159, default 65535): 2048
Last sector, +sectors or +size{K,M,G} (2048-167772159, default 167772159):
Using default value 167772159
----------------------
If "-c" option is used with the fdisk command:
The same applies but you should start at a value of 65536.
primary partition (1-4)
Partition number (1-4): 1
First sector (65535-524287999, default 131070): 65536
Last sector, +sectors or +size{K,M,G} (65536-524287999, default 524287999): 524287999
The key here is that the number used for starting the alignment properly should be dividable by 2048.
Taking the example above: 65536/2048 = 32 >>>> alignment is correct, 65536 can be used for aligning the partition.
65556/2048=32.00976 >>>> alignment incorrect therefore this value cannot be used.