although the 'geom' driver has the capability of assigning an LED to indicate activity, assigning "kern.geom.disk.mmcsd0.led" to the correct 'led' device name does NOT appear to work.
Upon further investigation, there appears to be no supporting code (i.e. calls to 'led_set' for example) in the mmcsd driver. And none of the code in the 'geom' driver appears to actually set the LED to 'on', except for errors.
I first observed this in FreeBSD 11.0 on the Raspberry Pi 2 (RPI2 kernel). I can still observe it in the latest '-STABLE' release as of last week.
I may be able to add a patch to this bug report that could possibly correct for this, either to the 'geom' driver or to the 'mmcsd' driver (as appropriate). In short, the mmcsd (or geom) driver would need to be updated to blink the LED in an appropriate manner while there is disk activity, using the appropriate sysctl variable (in this case, "kern.geom.disk.mmcsd0.led" or similar) to indicate which led to use (via 'led_set'), similar to some of the existing code in the geom driver.
'uname -a' string:
FreeBSD pi2b 11.1-STABLE FreeBSD 11.1-STABLE #0 r330739: Sat Mar 10 16:07:22 PST 2018 bobf@hack.SFT.local:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm
doing 'geom PART list' gives me this output:
Geom name: mmcsd0
1. Name: mmcsd0s1
Mediasize: 17805312 (17M)
2. Name: mmcsd0s2
Mediasize: 31897145856 (30G)
1. Name: mmcsd0
Mediasize: 31914983424 (30G)
Geom name: mmcsd0s2
1. Name: mmcsd0s2a
Mediasize: 31897092096 (30G)
1. Name: mmcsd0s2
Mediasize: 31897145856 (30G)
You may want to check out https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189788
This proposed patch (from 2014) added a hook to do what you want. Not sure if any work is necessary to update the patch to 11.1
that patch looks pretty close to what I was thinking, actually, based on the code already in the geom driver that blinks the led on error, and also turns it off in a few places, but never seems to turn it on.
The '!' is an interesting feature. Probably should be a separate patch, though. The 'led' driver handles polarity correctly if the DTD file has the right stuff in it to set the polarity [for example, the RPi model 1B has inverted polarity on the 'ok' LED].
someone in an IRC channel pointed out that the led device has enough inefficiency in it (due to looking up the LED pin name) to negatively impact the efficiency of disk access.
So a patch to the led device may be needed to make solving this both reasonable and practical.
cacheing an LED reference is one possibility, even if it's just "the last LED that was referenced", since disk access happens a LOT, and other kinds of LED activity typically don't.
If the LED device were to be destroyed or altered, the led driver could flush the cache.
(In reply to bobf from comment #3)
You may want to benchmark first. Originally I had thought there must be an impact, but in my tests (RPi, BBB, APU) there was no measurable difference (diskinfo, buildworld), so I abandoned any attempt at LED driver optimization. YMMV!