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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276522

--- Comment #5 from rm@richardmay.net <rm@richardmay.net> ---
To the best of my knowledge ESXi 4kn support encompasses only local disks.

For remote (SAN) storage ESXi appears tolerant of varying physical block sizes
(pblocksize) but is *not* tolerant of anything but 512 byte logical blocks --
in my experience.

Article ID: 327012 at
https://knowledge.broadcom.com/external/article?legacyId=2091600 touches on
this but doesn't seem to make an explicit declaration here.  Over the years
I've spotted other verbiage within VMware docs that seems to corroborate ESXi +
remote storage only working with 512e or 512n.

FWIW I'm playing with this using 14.2-RELEASE and ESXi 8.0.3 build 24414501. 
I've set:

blocksize 4096
option pblocksize 8192

...and ESXi is unhappy about it.  It sees the empty LUN and appears to work
until you begin the format process (from within vCenter).  Then the storage
path drops.  I can't find anything in hostd.log, vmkernel.log, or anywhere else
that's intuitive or descriptive -- just a dead path as if someone pulled a
cable.

It seems fine with:

blocksize 512
option pblocksize 8192

...though "esxcli storage core device capacity list" worryingly lists the
Format Type as Unknown.

I'm thinking the best plan here is:

blocksize 512
option pblocksize 4096

...the latter effectively hides zvol volblocksize rather than passing it
through. This keeps ESXi logfiles clear and the disk sector format listed as a
comforting 512e.

Let me know if I can help test anything. ESXi seems to be a small but
persistent pain point when people point it toward *nix block storage targets. 
I've got it working fairly well over here.

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