From nobody Mon Apr 18 17:47:27 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 9637D11E778B
	for <freebsd-scsi@mlmmj.nyi.freebsd.org>; Mon, 18 Apr 2022 17:47:40 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KhvXW6FQSz3hcF
	for <freebsd-scsi@freebsd.org>; Mon, 18 Apr 2022 17:47:39 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe34.google.com with SMTP id v133so9761911vsv.7
        for <freebsd-scsi@freebsd.org>; Mon, 18 Apr 2022 10:47:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=uJ7nIKvxz6+vFf96cmpI0hla5DItUAmYqsZZ+yaN3SY=;
        b=ObRKnW+mg3TswM+s3yGvefHbRn32aH+00jfkboc2xTlPEO1FCXhPQ/yFxNKJqmyXcl
         MUsEwWqiGLjI5p0TNHrVmN5AFKn8OS7WW301MXrrlEl9tcrv717S0gUPg78/dZPvRp/s
         iEQq6D/9JAoxsLNM8s8YVQoSUlx2xvlvHXVZqe+5F2Irm0NzupFEHoOVvHHU3h82Nq3K
         ODiELaufw/mjDAQWDciRBnB9fAoiit37hQ1ltGRVnReuD6/IAX9ZBwEv49w4rHTZqkmY
         i6tM6ctqzuqYwQgqNH3P1Bueebs8e1liF9Dixo6znOBgcp3GNN82A3kCBXgBhwb5W64W
         JhFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=uJ7nIKvxz6+vFf96cmpI0hla5DItUAmYqsZZ+yaN3SY=;
        b=I+HxydyKDLyZgYE1PEtembktBfm2LbKz+mLr0Mz8H0e11JUXOZwKwn/K9hF4e3DhU6
         ULNOaON8YXGSS+0zytZJ7hlOXwyK2cW47fBet+J9NyLsHcnPXbwwTN84X9VLXV8MggzX
         7EudESJNPvwmvCnRuzRbqY6yMaroUjTWbWawXOR5Ynh/NGA3owz4+/QjE4QR3SJQ3y30
         iA/jpS1Fd+rizlKJgHng2Hewpn7rmpd/zICk11YBmdKV925biPRNACOcQ4EywKXEyr6A
         5pS+cZgp1pbrKJLRKih6UmIzhslmCD3C5uGHeCkh0+/+Pi7liikjzZiabSJexVX9h69L
         Omxg==
X-Gm-Message-State: AOAM531alQ7sxdpNOe0RXWiM64L7NpiKbLF8mA2aeGRwzEWVCNAI7TBX
	JvQ+9CY8NEjK1mESCWSaSIgAYMuXDobFrt6OaIXZ/xVQ9YkNoA==
X-Google-Smtp-Source: ABdhPJy8FlxTCSAGRa+KjUOewuIBCIuMf8LnvsZtvDiRSdSRt84XI3TeB5F/sg9r4e7tZCDIY1P3ydPSXJTlBUrTcpo=
X-Received: by 2002:a67:746:0:b0:328:33e3:6079 with SMTP id
 67-20020a670746000000b0032833e36079mr3295596vsh.17.1650304058794; Mon, 18 Apr
 2022 10:47:38 -0700 (PDT)
List-Id: SCSI subsystem <freebsd-scsi.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-scsi
List-Help: <mailto:scsi+help@freebsd.org>
List-Post: <mailto:scsi@freebsd.org>
List-Subscribe: <mailto:scsi+subscribe@freebsd.org>
List-Unsubscribe: <mailto:scsi+unsubscribe@freebsd.org>
Sender: owner-freebsd-scsi@freebsd.org
X-BeenThere: freebsd-scsi@freebsd.org
MIME-Version: 1.0
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 18 Apr 2022 11:47:27 -0600
Message-ID: <CANCZdfr7u0Emk=+6butKsjAgYcgJhvTZu3rv7X6N6Pozdx7tcA@mail.gmail.com>
Subject: WWN
To: freebsd-scsi <freebsd-scsi@freebsd.org>
Content-Type: multipart/alternative; boundary="00000000000032389405dcf15b3d"
X-Rspamd-Queue-Id: 4KhvXW6FQSz3hcF
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=ObRKnW+m;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e34) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [1.22 / 15.00];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-scsi@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 NEURAL_SPAM_MEDIUM(1.00)[0.999];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_SPAM_LONG(1.00)[0.995];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e34:from];
	 SUBJ_ALL_CAPS(0.23)[3];
	 MLMMJ_DEST(0.00)[freebsd-scsi];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000032389405dcf15b3d
Content-Type: text/plain; charset="UTF-8"

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?

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.

Warner

--00000000000032389405dcf15b3d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is there a reason we don&#39;t rely primarily on WWN chang=
ing to detect a disk change at a particular location? I know it&#39;s not u=
niversally available, but anything made in the last 15 or 20 years should h=
ave one if my research is correct... Or is this just a case of inertia?<div=
><br></div><div>I&#39;m looking at making ahci a little more resilient to t=
ransient outages, and thought it might be best to key primarily off this an=
d secondarily off other changed information when that&#39;s not available. =
If I had a WWN, then I&#39;d know the disk that was gone for 500ms is the s=
ame one and I could resume its operations and still detect that someone unp=
lugged drive A and plugged in drive B.<br><div><br></div><div>Warner</div><=
div><br></div></div></div>

--00000000000032389405dcf15b3d--