[LEDE-DEV] "block" fstools wishlist

[Daniel Golle]

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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev