SAS Drives Showing 0B in lsblk and Missing from Multipath: The 520-Byte Sector Problem

Enterprise SAS SSDs — such as the Samsung ARFA7680S5 — are often shipped or repurposed from storage arrays (NetApp, EMC, etc.) with a non-standard sector size. These arrays use 520-byte sectors instead of the standard 512-byte sectors found on regular disks. The extra 8 bytes are the Data Integrity Field (T10 DIF/PI), used for end-to-end data integrity protection, allowing the array controllers to detect data corruption at every hop between host, HBA, expander, and disk. While this is valuable inside purpose-built storage arrays, it creates a hard incompatibility when the drives are repurposed and connected directly to a standard Linux host.

The Problem

Linux cannot read disks formatted with 520-byte sectors. When the Linux kernel detects an unsupported sector size, it logs a warning and gives up entirely — it will not attempt to read the disk, guess the size, or fall back gracefully:

sd 0:0:43:0: [sdal] Unsupported sector size 520.

This means the kernel sees the block device node (e.g. /dev/sdal) because the SAS HBA registered it, but it cannot interrogate the disk any further. The result is the device reporting zero size — showing up as 0B in lsblk.

This zero size is also why multipathd never creates a multipath device for these disks. Multipath requires a valid block device with a readable size and a WWID (World Wide Identifier) to group paths together. A 0B device provides neither, so multipathd silently skips it.

The Indicators

Look for these three symptoms together:

1. lsblk shows 0B for the affected drives:

sdak    66:64   0     0B  0 disk
sdal    66:80   0     0B  0 disk
sdam    66:96   0     0B  0 disk
sdan    66:112  0     0B  0 disk

2. No mpath device is created by multipathd for those drives, even though other disks on the same HBA are working fine.

3. dmesg shows the following for the same devices:

sd 0:0:43:0: [sdal] Unsupported sector size 520.

You can confirm the sector size directly using:

sg_readcap -l /dev/sdal
# Look for: Logical block length in bytes: 520

The Solution

The sg_format utility (part of the sg3-utils package) can issue a SCSI FORMAT UNIT command to the drive, which reformats it at the media level and allows changing the sector size. This is the same operation a storage array would perform when initializing a new drive.

Install sg3-utils and reformat to 512-byte sectors:

On RHEL/CentOS/Rocky:

dnf install sg3_utils

On Debian/Ubuntu:

apt install sg3-utils

Verify the current sector size first:

sg_readcap -l /dev/sdal

Reformat to 512-byte sectors — THIS DESTROYS ALL DATA:

sg_format --format --size=512 /dev/sdal

The command will display a 10-second countdown before proceeding, giving you a last chance to abort. The --format flag is required — without it, sg_format will only change metadata and not actually reformat the sectors.

Warnings

Data destruction. This operation destroys all data on the drive. There is no recovery. Ensure the drive is not in use and data is backed up before proceeding.

It takes time. A FORMAT UNIT is a destructive, touch-every-sector operation. A 3.84TB SSD can take anywhere from 10 minutes to over an hour depending on the drive model and firmware. Drives may get warm during this process — ensure adequate airflow.

Do not interrupt the process. Interrupting a FORMAT UNIT mid-way can leave the drive in an inconsistent state, potentially making it unreadable. If this happens, try running sg_format --format --size=520 first to return it to its original state, then reformat to 512.

If the drive refuses to format, it may be locked by a previous array controller. In that case, try running sg_format --format --size=520 first to unlock it, then immediately reformat to 512.

After the Fix

Once reformatted to 512-byte sectors, no further configuration is needed. The drives will:

• Show the correct size in lsblk
• Be fully readable by the kernel
• Expose their WWID to multipathd
• Appear as proper mpath devices automatically, assuming multipath is configured correctly for the device vendor/model

Verify with:

lsblk /dev/sdal
multipath -ll