I am trying to put together a complex setup (Debian) that uses LUKS+LVM+LVM cache in a mixed SSD+HD environment.

To use a partition on the SSD (partition size for lvmcache volumes: 20 GB) as the LVM cache, I need to add it to the same volume group as the volumes it is acting as a cache for. Those volumes will be located on HD (/home and /var/lib/docker).

I went through most of the manual installation steps (partitioning, encryption and unlocking) until I realized that I couldn't do that safely because the block sizes on the SSD partition and the HD partitions were different. By default, one gets 512 as the block size on the SSD, and 4096 as the block size on the HD.

How do I change the block size on the SSD partitions to 4096? There is no data on any of the disks, so I can do any destructive steps needed.

I assume that from a longevity standpoint, it is better to have a block size of 4096 on the SSD as that means fewer r/w cycles. I do lose some space, but I am not concerned about that since almost all the big partitions are going to be on HDs.


2 Answers 2


I assume you are trying to change the block size because LVM doesn't allow mixing PVs with different block sizes in one VG. You can change this in /etc/lvm/lvm.conf by changing allow_mixed_block_sizes to 1. But if you do this you must make sure to never create logical volumes that use both PVs, if you do that you will loose data (that's why LVM doesn't allow this by default). I don't know what will happen if the LV is on one PV and cache on the second one. It might work, because the data corruption with mixed sector size PVs happens on the filesystem level and the caching happens on the block level, so it might be safe, but I wouldn't risk it.

You can also "fix" this on the LUKS/dm-crypt level and create both LUKS devices with same 4096 sector size (option --sector-size 4096 with cryptsetup luksFormat) but you again risk data loss, in this case with power failures where dm-crypt cannot guarantee atomic writes on the 512 sector disk with 4096 sectors (you can create LUKS with integrity to prevent this, but at cost of performance and disk space).

I would probably switch the 4096 drive to 512 (if it supports that, most NVMe drives do), the performance loss here wouldn't be that bad.

  • My question has changed. Please take a look. Sorry about messing up my question yesterday. Commented Nov 8, 2021 at 16:28

According to the mke2fs manual page : -b block-size Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically determined by the filesystem size and the expected usage of the filesystem (see the -T option). If block-size is preceded by a negative sign ('-'), then mke2fs will use heuristics to determine the ap‐ propriate block size, with the constraint that the block size will be at least block-size bytes. This is useful for certain hardware devices which require that the blocksize be a multiple of 2k.

Then, the block size of the filesystem seems 1024 or higher (on ext2 and more). What you can’t change is the block size of the hardware, which is a behaviour of the hardware.

  • 1
    That doesn't help when building an LVM cache though Commented Nov 7, 2021 at 19:49
  • I have changed my question as I had, owing to fatigue, made mistakes in posing it. Commented Nov 8, 2021 at 16:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .