From nobody Mon Apr 18 22:17:44 2022 X-Original-To: freebsd-scsi@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 1AF9711E3C2F for ; Mon, 18 Apr 2022 22:17:55 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4Kj1XK6Tghz3j81 for ; Mon, 18 Apr 2022 22:17:53 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 1392832020F6; Mon, 18 Apr 2022 18:17:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 18 Apr 2022 18:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1650320265; x= 1650406665; bh=gTJj1rKBycyz0GeFt4QMPMdUrbGjKyCYU0PRJxYi6LM=; b=R LgfIp1xtz7/8qMZ7THL6cKtv8oMbvYBo8dIZTK8NKhQIzvjTLetXCAG9GJhVgC1+ fiSUJw0SLAdGNLzEjtUe+y/vED4C5h4565bS6IT83MjmXkRVr+54wQEIaUHlHVdf rwEN4y/T6MulS+P4A7Z48uGCiPI/be5Tt8FaUn2A8HXpaPNhelhDZAdcKpK2IdJ2 WWQMzv4vwgVT5zkm6hR3W3BSkgCh/7ALH5FT8G3YgOmja/riYY211ERIoH5J2L5Q AqyUfzh3cv+hkVbA5dlxTTeqoJGwso2p/xfA4IRRZUTpZJQXn+HaLbxhxf6mZbXo wfIr5D9uzJWiwGeSu2g/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1650320265; x=1650406665; bh=gTJj1rKBycyz0 GeFt4QMPMdUrbGjKyCYU0PRJxYi6LM=; b=Y8kCG8gC83BdzmzzkJrXT/8GY/6W5 iLsyN8cj/dq6ltmPVaLFJvIsq/FbJKuli1iTkKxXgegM84MHQ+QIEvRjcpdFYqxU HL8qhxfFhtZqq7lRIf1bomnNokxgFxnGvHaUxQ/Ua8e87oVlZlH8Oq5kuOVIEAC9 XVMkx61OR7zCt8bPqwxhGGOB8grdbNou1nNaVzFoXtqGfhjtbOkGVZJOC6F6UyZU pCU5eYSSuj2c4UyvFbMvGopPThU636SJp3n5YCo5bE2ZgdZJ/iiO880kxxrZ8sEY 8WKT2Pr+jqTfkSjjq34Xf9WSDx3BbZBy12K9UFOLuJY4vieE9pRsOpKgA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvddtvddgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepufgtohht thcunfhonhhguceoshgtohhtthhlsehsrghmshgtohdrohhrgheqnecuggftrfgrthhtvg hrnhepfeejgefgjefhgfdtjeevjeekgeevieelueehjefgudetvefgtdetgffggefgvdeg necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshgtoh htthhlsehsrghmshgtohdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 18 Apr 2022 18:17:44 -0400 (EDT) Content-Type: text/plain; charset=utf-8 List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: WWN From: Scott Long In-Reply-To: Date: Mon, 18 Apr 2022 16:17:44 -0600 Cc: Warner Losh , freebsd-scsi Content-Transfer-Encoding: quoted-printable Message-Id: <80C08AB3-C6BD-488D-A9B6-865ADEB186B2@samsco.org> References: To: David Gwynne X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4Kj1XK6Tghz3j81 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=samsco.org header.s=fm3 header.b="R LgfIp1"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=Y8kCG8gC; dmarc=none; spf=pass (mx1.freebsd.org: domain of scottl@samsco.org designates 64.147.123.24 as permitted sender) smtp.mailfrom=scottl@samsco.org X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[samsco.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.62)[-0.616]; SUBJ_ALL_CAPS(0.23)[3]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[samsco.org:s=fm3,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[scottl]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[samsco.org]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-scsi] X-ThisMailContainsUnwantedMimeParts: N You=E2=80=99re absolutely correct. 10 years ago, =E2=80=9Cgood=E2=80=9D = wasn=E2=80=99t even an option, but it was a reason why I wanted the = transport split out so that SCSI/SPI disk change detection could be = handled differently from SATA and from SAS. Since then, it=E2=80=99s = just been inertia, like Warner surmised. Scott > On Apr 18, 2022, at 3:28 PM, David Gwynne wrote: >=20 > don't let perfection get in the way of doing something good. >=20 >> On 19 Apr 2022, at 04:11, Scott Long wrote: >>=20 >> It=E2=80=99s been inertia from the hardware standpoint. SATA was = notorious for having unusable WWNs, serial numbers, etc. It=E2=80=99s = also been complicated by the varying quality of SATL and SATA-pass-thru = implementations in controllers (i.e. LSI). The Spectra guys probably = have a lot of good experience to share here. >>=20 >> Keep VM=E2=80=99s in mind though. Emulated environments don=E2=80=99t = always try very hard to generate unique IDs for storage. It might be = possible to heuristically figure out what kind of environment the system = is in and whether the IDs are dependable. >>=20 >> Scott >>=20 >>=20 >>> On Apr 18, 2022, at 11:47 AM, Warner Losh wrote: >>>=20 >>> Is there a reason we don't rely primarily on WWN changing to detect = a disk change at a particular location? I know it's not universally = available, but anything made in the last 15 or 20 years should have one = if my research is correct... Or is this just a case of inertia? >>>=20 >>> I'm looking at making ahci a little more resilient to transient = outages, and thought it might be best to key primarily off this and = secondarily off other changed information when that's not available. If = I had a WWN, then I'd know the disk that was gone for 500ms is the same = one and I could resume its operations and still detect that someone = unplugged drive A and plugged in drive B. >>>=20 >>> Warner >>>=20 >>=20 >>=20 >=20