From nobody Tue Feb 07 17:06:15 2023 X-Original-To: freebsd-geom@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 4PB8fw4V94z3nS99 for ; Tue, 7 Feb 2023 17:06:32 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (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 4PB8fv6mkJz480K for ; Tue, 7 Feb 2023 17:06:31 +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.217.51 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=none Received: by mail-vs1-f51.google.com with SMTP id g8so1697787vso.3 for ; Tue, 07 Feb 2023 09:06:31 -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:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=E4OhFCFo8VFDLkleIE0M0MZqtpR5s9iE8ZPsMDBO0cI=; b=MPQAytZySTmSDbXWpv0d9GZ2Q59uPnGZlEbjTHqAO1CislD/p6J0Uncj/MKnsq8rf4 aTZSmu+asjs4cGpAUI2BoOF3P6pFHmymElPfc3aM5buvsjLtKS0Lz/T/BJNhHfHPRWR2 1PIhJhS6xmqsf1H6e0xJyfZ+1WJ39gQWvC/pnTkkBimFRiZ86sapgcA6dH4Jl80VILKt HUCs0Ex5Mq+oh+cgL5sZdPY8t+GZwNzE/oO9dVMxxJdgbKSnviX7jd/CkH9brTzOc8bz cdGDPwTODLEVy80CqBk5cV+7cZHiGrF7/1Jq9pjDyT0V5+oGCitwOoNOZ6u9xxEXIRJ5 MWGg== X-Gm-Message-State: AO0yUKWYD14oRMqsdBtRncVxXX7btETUullSsZ9NsKTn0e+g0u/FRvEF Xgl56bFyo+NSCT66DLzWnkFcmIpXLWi+Rd1oD0tygtYJ X-Google-Smtp-Source: AK7set9f4eYOE5mGK07VJWp5gqj6AIFPJkIXKQWhT/m7h+IMpHKsftHrKaFgDa3K8yWK+n4jue2q6ZbK3nPWcKfYOnI= X-Received: by 2002:a67:845:0:b0:40d:dbb6:2ba9 with SMTP id 66-20020a670845000000b0040ddbb62ba9mr805365vsi.11.1675789586592; Tue, 07 Feb 2023 09:06:26 -0800 (PST) List-Id: GEOM-specific discussions and implementations List-Archive: https://lists.freebsd.org/archives/freebsd-geom List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-geom@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Tue, 7 Feb 2023 10:06:15 -0700 Message-ID: Subject: RFC: GEOM and hard disk LEDs To: freebsd-geom@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.84 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.84)[-0.841]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; MLMMJ_DEST(0.00)[freebsd-geom@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.217.51:from]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.217.51:from]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[asomers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-geom@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4PB8fv6mkJz480K 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.