Configuring a LINSTOR Cluster with Mixed Minimum I/O Size Storage Nodes

When you create or move a LINSTOR® resource onto a node, the operation can fail with an error saying that the storage pool has an incompatible minimum I/O size, even though the target node has sufficient free storage. This article explains what the error means and describes how to resolve it on a cluster with mixed block size backing devices.

Creating or moving a resource onto a node fails with an error similar to the following:

linstor resource create node-b pvc-[...]
ERROR:
Description:
    Cannot create resource 'pvc-[...]' on node
    'node-b', storage pool has an incompatible minimum I/O size
Details:
    Node(s): 'node-b', Resource: 'pvc-[...]'
command terminated with exit code 10

📝 NOTE: In a Kubernetes environment, the resource name is the persistent volume claim (PVC) name, and the resource create operation might be an attempt to add a replica of an existing volume to an additional node.

The error is not related to free capacity. It occurs when the minimum I/O size reported by the storage pool on the target node is larger than the block size that LINSTOR expects to use for the volume.

Minimum I/O size

The smallest I/O unit that a backing device advertises. LINSTOR records this per storage pool in the StorDriver/internal/minIoSize property, which it derives from the physical device backing the storage pool. Storage devices, whether NVMe drives, SATA or SAS SSDs, or HDDs, commonly advertise a minimum I/O size of either 512 bytes (512B) or 4096 bytes (4096B, also called 4K native or 4Kn), depending on how the drive is formatted.

DRBD block size

The logical block size that DRBD® exposes on the replicated device. Since LINSTOR version 1.33, LINSTOR automatically manages the DRBD block size for a volume. This is seamless when every node backing a resource uses the same block size.

LINSTOR shows the error when a resource was created with a volume block size derived from a 512B device, and you then try to place a replica of that resource on a node whose backing device is formatted for 4096B. The block size of the volume is smaller than the minimum I/O size that the target storage pool requires. In this case, LINSTOR refuses the placement rather than change the block size of a volume that might be in use. The reverse scenario does not trigger the incompatible minimum I/O size error, that is, you can place a replica of a 4096B volume on a 512B device, because a 512B minimum I/O size device can serve larger I/O requests, such as 4096B I/O.

To verify that the backing devices differ in block size across the nodes involved, follow these steps:

1. Inspect the minimum I/O size that LINSTOR recorded for each storage pool:

   linstor storage-pool list-properties <node_name> <storage_pool_name>
   

   Compare the StorDriver/internal/minIoSize value on the source node and the target node. A value of 512 on one node and 4096 on another confirms the mismatch.

2. On each node, examine the block size that the backing device reports:

   lsblk -o NAME,LOG-SEC,PHY-SEC
   blockdev --getss --getpbsz /dev/<device>
   

3. When the backing storage is LVM, show the logical volumes and their layout on the affected node:

   lvs -a
   

The correct resolution depends on whether you want LINSTOR to reconcile the block sizes for you, standardize on 4096B in software, or align the hardware formatting. For pure Linux file system workloads, file system I/O typically uses 4096B blocks regardless of the underlying device, so standardizing on a 4096B block size is safe.

However, exposing volumes with a 512B block size still has value for some workloads. For example, virtual machines running a legacy operating system that boots by using the traditional MS-DOS style MBR mechanism expect 512-byte sectors. Because a 4096B-formatted device cannot serve 512B writes, you cannot place a 512B volume replica on a node whose backing device uses 4096B sectors. To support such workloads, either format the backing drives across the cluster with 512-byte sectors (compare Option 3), or have a software layer that provides the necessary read-update-write semantics to expose 512B blocks on 4096B devices. For example, ZFS does this, so backing the LINSTOR storage pool with ZFS instead of LVM is one solution. Another is to emulate 512-byte sectors at an iSCSI target above LINSTOR (see the Related reading section).

There are three resolution options.

Automatic block size management is enabled by default in LINSTOR. If it was disabled in your cluster, you can enable it again at the controller level.

linstor controller set-property Linstor/Drbd/auto-block-size true

However, LINSTOR locks in the block size of a volume as soon as one of its resources becomes Primary, by setting the Linstor/Drbd/freeze-block-size property to True on the volume definition. A locked-in block size prevents the placement even when automatic block size management is enabled.

This resource placement preventing behavior is a safety measure. After a volume was exposed with a 512B block size and used, whatever was written to it, such as a partition table, boot loader, or file system, might depend on that minimum I/O size being preserved. Because LINSTOR cannot know whether the workload depends on 512B I/O, it takes the safe action of locking in the block size after the volume has been in use, and leaves the decision to change it to you.

To allow LINSTOR to change the block size of an affected volume, first verify that the data on the volume does not depend on the 512B I/O capability. For example, check that the partition table is GPT rather than MBR, and that any file systems on the volume use a block size of 4096B or larger. Next, verify that no resource of the resource definition is in a Primary role, for example by stopping the workload that uses the volume. Then clear the Linstor/Drbd/freeze-block-size property on the volume definition.

linstor volume-definition set-property \
  <resource_name> 0 Linstor/Drbd/freeze-block-size false

When you then add a replica on a 4096B node, LINSTOR increases the volume block size from 512B to 4096B. LINSTOR makes this change while the resource is not Primary, by cycling the DRBD resource down and up.

❗ IMPORTANT: Because of the down and up cycle, while LINSTOR increases the block size for a volume, that volume might be briefly unavailable for use. Plan to add the replica on a 4096B node during a scheduled maintenance window, or when the affected volume is not in active use.

To avoid the block size changing behavior of Option 1, you can tell LINSTOR to always expose 4096B block size volumes across the mixed cluster.

1. Turn off automatic block size management so that LINSTOR stops adjusting the value:

   linstor controller set-property Linstor/Drbd/auto-block-size false
   

2. Set the block size to 4096B. Apply it to specific resource groups through their volume groups, for example:

   linstor volume-group drbd-options <resource_group_name> 0 --block-size 4096
   

   Repeat the command for each resource group. Alternatively, set it once at the controller level so that it applies to all existing and future resource groups.

   linstor controller drbd-options --block-size 4096
   

3. Remove the per-volume block size settings that automatic management previously created on existing resources. Otherwise those settings continue to override the new value:

   linstor volume-definition drbd-options <resource_name> 0 --unset-block-size
   

   Rather than repeating the command manually for every existing resource definition, you can use a shell loop that covers every volume of every resource definition:

   linstor --machine-readable --output-version v1 volume-definition list \
   | jq -r '.[][] | .name as $rsc | .volume_definitions[] | "\($rsc) \(.volume_number)"' \
   | while read -r rsc_name vlm_nr; do
       linstor volume-definition drbd-options "$rsc_name" "$vlm_nr" --unset-block-size
   done
   

After you complete these steps, all existing and future resources and volumes use the 4096B block size, and the mismatch no longer prevents placement.

❗ IMPORTANT: Similar to Option 1, LINSTOR changes a volume that is currently exposed at 512B to 4096B by using a DRBD down and up cycle. Apply these changes when the affected volumes are not in active use, that is, during a planned system maintenance window.

A third option is to format the backing drives to a single block size across all nodes. Which block size to choose depends on your workloads: 4096B suits pure Linux file system workloads, while hosting virtual machines that run a legacy operating system requires 512B. This option gives you the most consistent long-term result, because it removes the mismatch at its source and keeps LINSTOR block size management straightforward, regardless of any of the settings shown earlier.

⚠️ WARNING: Reformatting a drive is destructive. Do it only on drives that have no data that you need, and drain or evacuate the node first. An interruption during the reformatting operation can render the drive inoperable.

💡 TIP: If you standardize the hardware on a single block size, you can leave Linstor/Drbd/auto-block-size enabled. With every backing device reporting the same block size, automatic management is seamless and no per-volume overrides are needed.

The exact reformatting procedure depends on the drive type. The following examples select 4096B sectors. Specify 512 instead, if you choose to standardize on 512B.

• For NVMe drives, use nvme format with the appropriate LBA format to select 4096B sectors.
• For SAS drives, use sg_format --format --size=4096 /dev/<device> to perform a low-level format with the new logical sector size.
• For SATA drives that support the SET SECTOR CONFIGURATION feature (marketed by Seagate as FastFormat), use hdparm --set-sector-size 4096 --please-destroy-my-drive /dev/<device> or openSeaChest_Format -d /dev/<device> --setSectorSize=4096.

Changing the logical sector size is generally an enterprise-class drive feature, and having 4096B physical sectors alone does not guarantee support. You can verify support in the product manual for the drive, or by querying the drive.

hdparm -I /dev/<device-identifier> | grep 'Sector size:'

A drive that supports changing the logical sector size will show multiple values.

Alternatively, you might query a drive by using a drive manufacturer-specific tool. For example, if querying a Seagate drive, use openSeaChest_Format -d /dev/<device-identifier> --showSupportedFormats.

When presenting storage over a network via iSCSI, and you want to use a different block size at the iSCSI target layer, rather than at the LINSTOR and DRBD layer, see Emulating 512 Byte Sectors on 4K Native Backing Storage over iSCSI.

As background, the storage industry itself initiated the change from 512B to 4096B sectors, and the industry association IDEMA made it a standard known as the Advanced Format in 2010. Larger sectors reduce the per-sector space required for the gap, sync, and address mark sections, and allow more efficient error correction codes. This raises the format efficiency of a drive from about 88% to about 97%, so drive manufacturers can present a larger net capacity from the same physical platters, along with improved error correction.¹

Written by PR and MAT, based on original notes from PR, 2026-08-10.

Reviewed by PR, 2026-08-06.