From nobody Wed Feb 08 06:56:13 2023 X-Original-To: freebsd-hackers@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 4PBW4W5CVfz3kpM9 for ; Wed, 8 Feb 2023 06:56:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 4PBW4W2zFmz3LGP; Wed, 8 Feb 2023 06:56:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102c.google.com with SMTP id f16-20020a17090a9b1000b0023058bbd7b2so1378300pjp.0; Tue, 07 Feb 2023 22:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3ySO/Tt+r/DxU6TkNC5vrPK42Rb4Cuzd+rC8poPqzeo=; b=IS3t+7WuokPmGm8b0V/gjy7oaFbF91/s6Lh6mIJMHAYkx0GchkzJ/cbNL6xm9Nmms9 8NXxC1awJXM6+Mfg1isZo7Lb5/fiJnMwkhymGmOpbNq1zFZMxloKT8UPsD+pnsiD4Sqg 4LWRX7+LPkmlHPtMMQ3eoGXgAlZ5a33gY2EUUd/j89rTwcDII6lAO/7OXV4+b5bZsG5o OJi5vFhyY5v/KfiCMXGc6xPb5Z4gEYp4jgJ1jOkywPnnSN+60ifbTXg3XglHAEHSBgpe 672mAhA6gsw+p/5DdsdQPb1YT6VfR1Wq/CfHycKUyX0pGQ5jgKoFgPreTV+mXnA6xmBS ZEcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3ySO/Tt+r/DxU6TkNC5vrPK42Rb4Cuzd+rC8poPqzeo=; b=s2H9o8zteFL3DVgrr8N/A5dLgT9ufhEEX+CEWbi+xS3m5sozkxzuddIOUyz9od8Z88 NEL15BhLbWXKG7B0/jRtIsOt9CFqdFnqS7t88KoftxmJQASeWBvKR1yMOWndt/DDfNU+ ARalT+oC7cxgZrabTpZwE+woP6gHMZ4j+5OrcIBzKinkWf/4UVLflqATu8FfORpwgCSW iLWBtF2IKDR5fm1QlDWpCRxJJa8vtrNT1BcvQHYzzqYY9n3oU8OUx8ROowm85h2NREqI pbfM3uAyXidBqOblTe6J4RRVU5VUFGhq7hyIzzuv1fA2UKHWEPQlBPGD2m6g8u2pSN3f 59hA== X-Gm-Message-State: AO0yUKXmx7ZsX+MN4dM5ywc6AwBgaHYQI6mdQkOgcFH5LDjwktM93e5V 31Ow5ltuzcZf3OU4g5RFXKXitESPZ3JCYg== X-Google-Smtp-Source: AK7set+9+CdTxjXe544B1CRuk/eG+6n15t7IarRF7lUN+lUbe3XnV77KRlopCOGDvNroigPa+NYY4Q== X-Received: by 2002:a17:902:ec89:b0:196:7bfb:f0d1 with SMTP id x9-20020a170902ec8900b001967bfbf0d1mr5938917plg.34.1675839385314; Tue, 07 Feb 2023 22:56:25 -0800 (PST) Received: from smtpclient.apple (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id b4-20020a170902d30400b00196077ba463sm10031034plc.123.2023.02.07.22.56.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2023 22:56:24 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DB28F257-4E7D-401D-BDAE-ABD8D26EDCC6"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: RFC: GEOM and hard disk LEDs From: Enji Cooper In-Reply-To: Date: Tue, 7 Feb 2023 22:56:13 -0800 Cc: FreeBSD Hackers Message-Id: <0155CD68-849E-40D6-95A5-6AAD5E229A57@gmail.com> References: To: Alan Somers X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PBW4W2zFmz3LGP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_DB28F257-4E7D-401D-BDAE-ABD8D26EDCC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 7, 2023, at 3:30 PM, Alan Somers wrote: >=20 > Most modern SES backplanes have two LEDs per hard disk. There's a > "fault" LED and a "locate" LED. You can control either one with > sesutil(8) or, with a little more work, sg_ses from > sysutils/sg3_utils. They're very handy for tasks like replacing a > failed disk, especially in large enclosures. However, there isn't any > way to automatically control them. It would be very convenient if, > for example, zfsd(8) could do it. Basically, it would just set the > fault LED for any disk that has been kicked out of a ZFS pool, and > clear it for any disk that is healthy or is being resilvered. But > zfsd does not do that. Instead, users' only options are to write a > custom daemon or to use sesutil by hand. Instead of forcing all of us > to write our own custom daemons, why not train zfsd to do it? >=20 > My proposal is to add boolean GEOM attributes for "fault" and > "locate". A userspace program would be able to look up their values > for any geom with DIOCGATTR. Setting them would require a new ioctl > (DIOCSATTR?). The disk class would issue a ENCIOC_SETELMSTAT to > actually change the LEDs whenever this attribute changes. GEOM > transforms such as geli would simply pass the attribute through to > lower layers. Many-to-one transforms like gmultipath would pass the > attribute through to all lower layers. zfsd could then set all vdevs' > fault attributes when it starts up, and adjust individual disk's as > appropriate on an event-driven basis. >=20 > Questions: >=20 > * Are there any obvious flaws in this plan, any reasons why GEOM > attributes can't be used this way? >=20 > * For one-to-many transforms like gpart the correct behavior is less > clear: what if a disk has two partitions in two different pools, and > one of them is healthy but the other isn't? >=20 > * Besides ZFS, are there any other systems that could take advantage? >=20 > * SATA enclosures uses SGPIO instead of SES. SGPIO is too limited, > IMHO, to be of almost any use at all. I suggest not even trying to > make it work with this scheme. Out of curiosity, is there a way that a client of zfsd could = instead reach out to zfsd via a pipe, etc, when an event triggered by = devd occurs? Just trying to think of a way that would result in a cleaner = architecture than having zfsd doing a busy-loop of some kind waiting for = an event to happen. Thanks, -Enji --Apple-Mail=_DB28F257-4E7D-401D-BDAE-ABD8D26EDCC6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmPjR40ACgkQ5JFNMZeD GN6Ftg//cFCiDTr0UrqU7yPRSHNICezO6VjKHyPDBFjroIkmREmfVT3dDMhn1K3X y7TmsHLN6B9QrP9hr7HkCzHcAAME7Y7KTmL4Fva1uxUMwq+JNrGu1jERJKTLpoCB aLjTgWY3An7bK0Mg5qKTNTDpOyEIbp2seWhKzpyE6/enRaXzSFtm48TLoUAK6K4f pjMHXQxtL23+qInbkM9w1HDvK+eUU3v8u1LScVDloUQJp1rk2ySVJLfHu1wzdmua as/2mkX+JF48B9LKitX2vJGCcvPn6b9TucZEcBD9lXcMT50fpnk5KX0ts+HKRzO4 LfpoFP/6V1bOwrMlw+pged7UYpi1pmTmSbrOPgyOe3D/UH57uQH8l6mNKlWqjdC/ exoM5/7RNOAiQaTJsuewM4gGAmrixzTG6RPpNGsMHWioE8UWI8zQqRNlP9TB2+cF Vv3fQXad+MgsdKVsmKfkH6bDJTM0fACDQFSimmze7L3kNC105Pph/ZGcWDWQe7OW syrnHIcqDPuP2ElDCgRsQE+6MGlQEsoBokmQz8lkdjzlLFsn3WfisdMzLb7wSniy KHs2q2KOTamuHh0hoGd46IJUzW0b2yffLikONRg7Ao0opi1LSPFeRJfiy979Qd4s HI8ylwdc/y53N+MK8EWqhhvmvGl37jEwunAQR8MVtWXkgkszw7Q= =rYWb -----END PGP SIGNATURE----- --Apple-Mail=_DB28F257-4E7D-401D-BDAE-ABD8D26EDCC6--