From nobody Sat Jan 18 07:46:05 2025 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YZpZ50XW4z5l0bL for ; Sat, 18 Jan 2025 07:46:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YZpZ46ygbz4520 for ; Sat, 18 Jan 2025 07:46:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1737186365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ob4cHIK0M6VpvubkhhKu0in0vkD3HvWbYgvGf7E+GAw=; b=M9/xGjQFqAi5NNBg4niBVFSdXhbZn+Fgx6Ghyy/O+oUFW337sOVOgyBu6+A4v3Rqp9CGyG 6UZbtcUds7tECnOyOooz6UH0alXQPIRLnnTeKmRRqK93kdvDBH2JLGeHxy37z2yVDTv3cW PYB2fUzOPMk3sgjbaIPV4SbMbpqnEdhzU7zsqty7JKq48Ysld3983S9liu3tpPgTbZOAWk dzzd+6iIjnEvnVFa/TPanx+41ROLKkP5eyyPNeQL3LWh1EwRMwp7PRN/6RWz1Tk8UiIsOw sbCp657+/4G77ptr4U4LuEbB2T8PkfL6WOEf7e++QthpXak9fA0Ge6XOuQCD3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1737186365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ob4cHIK0M6VpvubkhhKu0in0vkD3HvWbYgvGf7E+GAw=; b=tmcFLzOlyjHB90EXFAGwLEPnAB8oS1J2BO9hLvEYOC16IuGZkFlxSvTY8wOx22oPK+PCcM wkYbfJnY8k1mkIbkGqcfHjFSNEq2AM1TlaWRnAgyzbvMJ7bIrrX4fT3I3wlbMwKLJX7mEX 3nnH+srIV7Kiln/dngH6AzN3DcaCRpWCrQVPjYG6W0TuX+L8umhQqCoDwsuJy5+ZnIHI97 veGhmp5kSPcegNzUwfnekQbsU+1U6NtizY1YDSMTbECBtnbKIC4JoGLHS0Z8YF4elYttcI vvaS0hbpDBopHMkzRxUTw0uiV1VDhVw5Iu4VXNew7rqWhwlzQYYyvadVgpriJQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1737186365; a=rsa-sha256; cv=none; b=uaWg1aHk6Y3Yn7SepJX5+P0kxsf1eDsRdIa/6LkJMnZWu3QSzjKVIM9Y8ytfBwjrjwExzD Ny4ksU4suxzZX/wDBJkdyzyrxc3g9hf/rMtpgHJ83mwpwDCVNDBoFyFWyeReyaYKhDTOsa GvcOxDp84kLpBEHtHpjgpqTPLQv4L4RM9OLbotyj2G7mnLjHZ4jtZ1vU94CPg0FpyUDT5R z+ScxE6AeliDPcPoWSyPnQMHoBc999vcK5kUew9Yf7tkWY+gXMJC32Cl02CthhpI6V8rti 6oRjoBJ0ZD3ohgkPVmWUjPZMNx+U76f68oIAU38GPV6WiqD2N4viIc87PkTjMA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4YZpZ46ZCrzvmX for ; Sat, 18 Jan 2025 07:46:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 50I7k4FL097699 for ; Sat, 18 Jan 2025 07:46:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 50I7k43D097698 for virtualization@FreeBSD.org; Sat, 18 Jan 2025 07:46:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 276522] Setting LUN block size in ctl.conf to 4K causes mismatched block size and crashes in initiators Date: Sat, 18 Jan 2025 07:46:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rm@richardmay.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276522 --- Comment #5 from 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 si= zes (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=3D2091600 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 ES= Xi + 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= .=20 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 a= s 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 target= s.=20 I've got it working fairly well over here. --=20 You are receiving this mail because: You are the assignee for the bug.=