From nobody Mon Mar 27 19:54:19 2023 X-Original-To: freebsd-current@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 4Plk6d0f77z420KX for ; Mon, 27 Mar 2023 19:54:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (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 4Plk6c0GF0z3HtK for ; Mon, 27 Mar 2023 19:54:32 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.50 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=none Received: by mail-ua1-f50.google.com with SMTP id g23so7250187uak.7 for ; Mon, 27 Mar 2023 12:54:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679946870; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dvRlp5g90uzvIstDe5bx1x1mZ6Ppdls9bhZk72RtN9s=; b=ulj44vTRZ8+DBQEO5J5NNFTxiEcKi2RA7pEW6ounuHU5T2beuwYKdh2eZZ8CM7RJgb deCRATD2d7te+hxckti9KieTUBQW0Zd5VZ9QtWjLUp/q57Jk2SdkS+bFLlg8UGS0WCuR lj9ijR7g1IE6rkuDhxO5Ri59WLNWQVN0JTdFiQaaQ/+vgkQ7fOJDuEcPQyd4NJsqlcLL PsPvZR6bDXVQulCBTlzYdGAWhW+0+YKETpHGvL7+luC02MyZa0cCucYXz0HfI39Xzx3o DDmM9IYaD9UdgHNtOGmooOSSoePwNkDIb3Som/V9765wIeubWmj0iriRlBOviJb1+Ymj akYA== X-Gm-Message-State: AAQBX9e80Hrsswx2/4VF7Nte8J7HgiraabC+sYLkM9rduCvcEnApIloJ SPFTtEc2fI4lK0v7M2JeeZFG7zoA9DR4eSeVEnLDH4jixvo= X-Google-Smtp-Source: AKy350ZeJ6i8sSN+v5hxBuaVe7v9mgjmSB8iLCwKfw4aRigeraJL6k3yjAJIOUN08AASxfSBgqnlO08UJ5JF5KyCmTM= X-Received: by 2002:a1f:2fd8:0:b0:40c:4d1:b550 with SMTP id v207-20020a1f2fd8000000b0040c04d1b550mr7113577vkv.0.1679946870655; Mon, 27 Mar 2023 12:54:30 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Mon, 27 Mar 2023 12:54:19 -0700 Message-ID: Subject: head's up: disk physical paths changing To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.85 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.85)[-0.849]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.50:from]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.50:from]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[asomers]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4Plk6c0GF0z3HtK X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N I'm planning to commit a change to the format of disk physical paths, as reported by DIOCGPHYSPATH, and viewable by "diskinfo -v". This will only affect disks in a SES enclosure (which are most SAS enclosures with more than about 8 slots). Technically, this is a backwards-incompatible change. But I only know of two cases that are likely to be affected: * If anybody uses a /dev/enc@... device alias in /etc/fstab, they'll need to update it. * If anybody is using zfsd with autoreplace-by-physical-path, *and* happens to have a disk missing at the time they install this change, then zfsd won't autoreplace it when they replace the disk. They'll have to replace the disk manually with "zpool replace". If you think this will be a problem, or if you've thought of any more cases I haven't, then speak up. I'll commit in 2 weeks if nobody objects. https://reviews.freebsd.org/D39141