Hi Karl, I thought a bit about fstools since your post because I also had my difficulties integrating it with applications which require hotplug storage. I agree with and acknowledge all the points you mentioned.
In addition I believe that LEDE/OpenWrt generally lacks a high-level concept to integrate optional block storage. Imho something like /data on Android (or just mount it to /var?) would be nice and make setting up services much easier, also without using extroot. Just a missing convention to agree on. It could be a symlink to /mnt/sda1 or /mnt/mmcblock0p1 or whatever is detected first on a specific device. autofs4 with mountd does the job well imho, I didn't have problems with that. What's needed are sane defaults depending on the type of hardware (both, board-type and detected storage peripherals). And a simple one-click "initialize storage device XYZ and use it per default for all on this system". That should do partitioning, mkfs and setup fstab. More complex setups with md raid or even LVM2 and cryptsetup mark the top-edge of the model. I suggest we should draft the structures and api in some etherpad and then implement an *optional* storage management service based on fstools and replacing/extending block-mount. Adding hotplug handlers for block devices should then become rather trivial. It'd also be nice to have a "large block storage is now mounted" runlevel, so services depending on that (think: squid, postgresql, git server, ...) would be started only once the block device has settled and was mounted. This would allow things like databases or other apps which require storage to create their filessytem structures automatically in the package's post-inst-on-target aka. uci-defaults script and have a sane default set in their configurations. (I'd very much like to have that e.g. for postgresql, and also offer some functions in a to-be-created /lib/functions/postgresql.sh for packages to setup databases) If anyone can setup an etherpad in the meantime I'll happily start adding my suggestings to the spec once I got some sleep... Cheers Daniel On Wed, May 18, 2016 at 04:45:57PM -0000, Karl Palsson wrote: > > Listing out a few things I've found with fstools package > (Version: 2016-05-17-db5d39d48b9d9a77565015c1aafb3ef0d2925f02) > I'm mostly still working on openwrt CC branch, but the issues > _seem_ to be fstools related, not kernel related, though I'm > happy to retest if necessary. Some of these I've discussed on irc > with blogic and jow, others just here, posting them here for > posterity as they're bigger than quick fixes on IRC. Further, > this is largely an area I'm not really comfortable trying to hack > up patches, they need to follow the style and direction of the > project more than just my specific needs, so I can't post patches > for any of these. > > * block mount mounts _and_ turns swap on. block umount only unmounts. > Shouldn't it swapoff as well? > > * "block" anything can't have it's output captured. The checks in libubox: > ulog.c:: ulog_defaults() detect the attempt at capturing the output as a !tty > and write to syslog instead. > > * block doesn't handle hotplug. This is probably the biggest thing. This > overlaps with the old and unmaintained "mountd" package, which blogic > expressed interesting destroying/merging/combining with "fstools" This > doesn't seem to be a problem for usb sticks, because the removal of the stick > removes the entire device node well. However, an SD card in a slot maintains > a /dev/sda entry even after the card is removed. "block info" will fail to > see new block details if a partition was mounted, or as activated swap, and > swap and mounts are not turned off when the card is removed. > > I wrote about various trials and tribulations with mountd vs > block here > https://lists.openwrt.org/pipermail/openwrt-devel/2016-February/039798.html > and resolved that I would simply poll "block info" every couple > of seconds. Unfortunately, that ended up being rather noticeable > CPU load, so I'm still looking for neat ways of handling sdcards, > and while mountd noticed disk changes, it failed at reliably > mounting/unmounting, and most importantly, was and is clearly > regarded as "not the right way" going forward. > > Desktop linux mostly solves this with udisks/udisks2, and at the moment, > something functionally equivalent is rather missing from the lede user space > world. > > Cheers, > Karl P > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
