[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b108799e-24a2-d5ec-e18e-b7ae8bded085@gmail.com>
Date: Thu, 29 Jul 2021 12:03:04 -0500
From: Ian Pilcher <arequipeno@...il.com>
To: Pavel Machek <pavel@....cz>
Cc: linux-block@...r.kernel.org, linux-leds@...r.kernel.org,
axboe@...nel.dk, linux-kernel@...r.kernel.org,
kernelnewbies@...nelnewbies.org
Subject: Re: [RFC PATCH 0/8] Add configurable block device LED triggers
On 7/29/21 3:54 AM, Pavel Machek wrote:
> We normally have a trigger ("block device activity") which can then
> expose parameters ("I watch for read" and "I monitor sda1").
>
> Is there a reason normal solution can not be used?
This big difference is that this allows different devices to drive
different LEDs. For example, my NAS has 5 drive bays, each of which
has its own activity LED. With these patches, I can create a
separate trigger for each of those LEDs and associate the drive in each
bay with the correct LED:
sdb --> trigger1 --> LED1
⋮ ⋮ ⋮
sdf --> trigger5 --> LED5
(sda is the SATA DOM boot drive.)
Note that this also supports associating multiple devices with a single
trigger, so it can be used for more complicated schemes. For example,
if my NAS had an additional LED and an optical drive, I could do this:
sr0 --+
|
+--> trigger0 --> LED0
|
sda --+
sdb -----> trigger1 --> LED1
⋮ ⋮ ⋮
sdf -----> trigger5 --> LED5
As far as I know, the current triggers (disk-activity, disk-read,
disk-write, and ide-disk) don't support this sort of arbitrary
device-trigger association.
This patch set also support triggering LEDs from pretty much any block
device (virtual as well as physical), not just ATA devices, although
that's just a matter of the place from which the trigger is "fired".
I hope this explains things.
Thanks!
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
Powered by blists - more mailing lists