Re: [LEDE-DEV] replacing mountd with blockd - looking for testers
On Mon, Feb 27, 2017 at 11:48:23AM +0100, John Crispin wrote: > On 27/02/2017 11:43, Alberto Bursi wrote: > > There are quite a few NAS devices that have 2+ disk activity leds (one > > for each disk) that could really use a generic system instead of adding > > patches to drivers/kernel. > > dont get this, why is a kernel patch required ? if there is an > appropriate trigger at hand, we will use it otherwise it will be > > * off - no device attached > * on - device attached > * blink - device mounted There are devices (like the KD20) which got 2 LEDs for each S-ATA port: a red one to indicate a faulty disk and a blue to indicate link-up and port activity. Will, I wrote this patch a long while ago (and use it on oxnas) https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/834-ledtrig-libata.patch Maybe this LED trigger could take a parameter from userspace to indicate the mount-status as well (unless there is a way to get use-count from inside the libata subsystem?) Anyway, I tried submitting this upstream and it was deleted from their patchwork within a day with no reason given what-so-ever, I guess because they believe that the generic 'disk' led-trigger is good enough... Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing mountd with blockd - looking for testers
On 02/27/2017 11:48 AM, John Crispin wrote: > > > > dont get this, why is a kernel patch required ? That's how I saw some of such NAS stock firmwares (and some Debian/Arch for ARM targeting those devices) do. Someone patched the sata driver (and the kernel) to create a "sata activity on port X" trigger that will show disk activity on "sata port X" (devices that have at least 2 sata ports, usually have a sata led per disk) The Sata led trigger from upstream will trigger on ANY activity on Sata, so it's not useful to drive more than one Sata led. > * off - no device attached > * on - device attached > * blink - device mounted > Hm, better than nothing. I think the above led behaviours should be user-configurable though. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing mountd with blockd - looking for testers
On 27/02/2017 11:36, Daniel Golle wrote: > Hi John, > > On Mon, Feb 27, 2017 at 11:20:40AM +0100, John Crispin wrote: >> Hi, >> >> i have created a branch in my staging tree [1] that removes mountd in >> favour of blockd. blockd is part of the fstools package and uses the >> block tool and /etc/config/fstab as a backend. >> >> blockd is an optional daemon and when installed will provide these >> features in addition to what block-mount already does : >> >> * autofs4 support >> * ubus call block info - for status info on attached block devices >> * reload_config support - mount move or change from named to autofs to >> anon mounts > > Great news! > >> >> What else should we add : >> >> * support for eject buttons and LEDs >> * ubus notifications upon state changes >> * ubus interface for mount/unmount >> * anything else that folks might like to see being added ? > > I haven't had a look at your work yet, so something might already > be supported implicitely. However, I imagine it'd be useful to have > * waiting with service bring-up until specific device got mounted >(eg. for transmission or postgresql) we could add this to blockd but would need to figure out where to put this info. maybe add it as private data to the service/instance inside procd ? > * support for attaching and activating LVM2 volumes > * support for using cryptsetup to open LUKS and TrueCrypt volumes >see https://github.com/openwrt/packages/pull/3259 these are really features that should be added to block-mount ? John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing mountd with blockd - looking for testers
On 27/02/2017 11:43, Alberto Bursi wrote: > > > On 02/27/2017 11:20 AM, John Crispin wrote: >> Hi, >> >> * support for eject buttons and LEDs > > Can this daemon light up a led every time a specific mounted partition > is accessed (read/written)? not yet, which is why this action item is listed under the "What else should we add" section. however the idea is that you can specify the led either in the mount section or the global section. > > There are quite a few NAS devices that have 2+ disk activity leds (one > for each disk) that could really use a generic system instead of adding > patches to drivers/kernel. dont get this, why is a kernel patch required ? if there is an appropriate trigger at hand, we will use it otherwise it will be * off - no device attached * on - device attached * blink - device mounted John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] replacing mountd with blockd - looking for testers
Hi, i have created a branch in my staging tree [1] that removes mountd in favour of blockd. blockd is part of the fstools package and uses the block tool and /etc/config/fstab as a backend. blockd is an optional daemon and when installed will provide these features in addition to what block-mount already does : * autofs4 support * ubus call block info - for status info on attached block devices * reload_config support - mount move or change from named to autofs to anon mounts What else should we add : * support for eject buttons and LEDs * ubus notifications upon state changes * ubus interface for mount/unmount * anything else that folks might like to see being added ? Please help test the new daemon. John [1] https://git.lede-project.org/?p=lede/blogic/staging.git;a=shortlog;h=refs/heads/blockd ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
