[Bug 276522] Setting LUN block size in ctl.conf to 4K causes mismatched block size and crashes in initiators

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 19 Jan 2025 20:24:12 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276522

--- Comment #9 from rm@richardmay.net <rm@richardmay.net> ---
(In reply to balchen from comment #8)

I see the [possible] discrepancy after reading your bug report more carefully.

Your ESXi host was somehow detecting "current logical block size 512" and yet
"Mode Sense cmd reported block size 4096" per vmkernel.log.

So ctl's response to the mode sense query was correct ("4k logical") and yet
ESXi still thought "current logical block size" was 512 -- the implication
being ctl *could* have given a wrong answer to a prior and different query.  It
begs the question of what gave ESXi that impression.

ESXi detecting an existing on-disk format from a prior boot could be one
source.  ESXi is notoriously "sticky" about block devices -- it seems to cache
details about said devices and their filesystems and throws toys out of the
crib when something different shows up purporting to carry the same volume.  Or
when a different volume arrives on a familiar device.  Hence the existence of
hacks like LVM.EnableResignature, SCSI.CompareLUNNumber, and
LVM.DisallowSnapshotLUN.

For sure 512e (i.e. blocksize 512 with option pblocksize 4096) is almost
certainly the best path forward.  I've checked the kernel logs from my
experiments and found your exact same error on five occasions.  An explicit
512e setup "just works" thankfully.

-- 
You are receiving this mail because:
You are the assignee for the bug.