From nobody Tue Feb 07 23:30:43 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 4PBKBV0mJ6z3nrlv for ; Tue, 7 Feb 2023 23:30:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 4PBKBT1yKBz3sCP for ; Tue, 7 Feb 2023 23:30:57 +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.45 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=none Received: by mail-ua1-f45.google.com with SMTP id b18so3076630uan.11 for ; Tue, 07 Feb 2023 15:30:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9PF90ic+mQSSwesONnXBJVRHNM4+pAvMJ47WhfGldM0=; b=bKRX/+SqMjLHXknQh8RX25o2riJPyQ63synhefLlMWScMNB88Y0JfgQPybIwKzARSc 7WMGujSkPYoh8tNQOaUBsO3ENGHgWHEpJ8KJRL9akRd+imdiBUWAH26m1Tpoq2u0mlym 2d+JPzvZupJ+93SrWVefNZIQnK2RWhkfTWIaLZvhh89YzKy17+kQm8EFQ4ks2OI9VcmF rxmZjoMTA7rcHziYcUR7odzbsGH7CbJt1w+lkGzPlxMQSJXoY/1hGHV2yvOnZcY+7tWe IdX6OIegbQ5pvRBomlxrVwufdjyzz1WYWoJE1SE5/LYnThJ3VpAPo27MmQiFxgQI4yMl 6pXA== X-Gm-Message-State: AO0yUKVkPWZfKF81VofGnmJjVxFDuibik8/ASspxcR8HUnjC7jpUVLzD VPEGiIaTY2ZR/O0+zuHj8NVv6PZ6gvBGkdW9CNcTyvJd X-Google-Smtp-Source: AK7set8lOwgV3he8Px00r0VFtyPqllSksnxWSotTZQ9IuLpgPfWz+Yb6K5hGq3j0hxKM+S4i+vgCP/LLqWwOoZjZufg= X-Received: by 2002:ab0:6644:0:b0:65a:ed38:427a with SMTP id b4-20020ab06644000000b0065aed38427amr1185471uaq.21.1675812655411; Tue, 07 Feb 2023 15:30:55 -0800 (PST) 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 References: In-Reply-To: From: Alan Somers Date: Tue, 7 Feb 2023 16:30:43 -0700 Message-ID: Subject: Fwd: RFC: GEOM and hard disk LEDs To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.93)[-0.934]; 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.45: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-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.45: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-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4PBKBT1yKBz3sCP X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N 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? 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. Questions: * Are there any obvious flaws in this plan, any reasons why GEOM attributes can't be used this way? * 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? * Besides ZFS, are there any other systems that could take advantage? * 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.