2019年8月20日(火) 3:38 Jacek Anaszewski <jacek.anaszew...@gmail.com>: > > On 8/19/19 8:22 PM, Jacek Anaszewski wrote: > > On 8/19/19 4:38 PM, Pavel Machek wrote: > >> On Sat 2019-08-17 22:07:43, Jacek Anaszewski wrote: > >>> On 8/17/19 4:55 PM, Pavel Machek wrote: > >>>> On Fri 2019-08-16 01:59:58, Akinobu Mita wrote: > >>>>> This allows LEDs to be controlled by block device activity. > >>>>> > >>>>> We already have ledtrig-disk (LED disk activity trigger), but the lower > >>>>> level disk drivers need to utilize ledtrig_disk_activity() to make the > >>>>> LED blink. > >>>>> > >>>>> The LED block device trigger doesn't require the lower level drivers to > >>>>> have any instrumentation. The activity is collected by polling the disk > >>>>> stats. > >>>>> > >>>>> Example: > >>>>> > >>>>> echo block-nvme0n1 > /sys/class/leds/diy/trigger > >>>> > >>>> Lets use one trigger "block" and have the device as a parameter, > >>>> please. > >>>> > >>>> We already have 1000 cpu triggers on 1000 cpu machines, and yes, its a > >>>> disaster we'll need to fix. Lets not repeat the same mistake here. > >>>> > >>>> I guess it may be slightly more work. Sorry about that. > >>> > >>> We should be able to list available block devices to set, > >>> so the problem would be not avoided anyway. > >> > >> Should we? We need to list triggers, but we may not list all the devices... > > > > This is similar to usbport trigger that lists available > > ports as files in a sub-directory. We might eventually go > > in this direction. > > I must withdraw this statement. This is not similar to usbport > trigger. The difference is that with ledtrig-block we have separate > triggers per each device and I am not aware if there is some centralized > mechanism similar to blocking_notifier_chain (usb_notifier_list > in drivers/usb/core/notify.c) available for block devices, that > would allow to gather all available block devs under common trigger. > > Moreover I remember Greg once discouraged using notifier chains > as they are unsafe, so we would need some other solution anyway.
I start thinking that we should implement the LED block device activity trigger in userspace. The userspace application firstly activates one-shot LED trigger and periodically reads /sys/block/<disk>/stat and writes /sys/class/leds/<led>/shot if there is any disk activity.
