Resent to list. 2018-08-13 21:43 GMT+02:00 Kai Krakow <kai@xxxxxxxxxxx>: > Hello! > > 2018-08-12 2:44 GMT+02:00 Vojtech Pavlik <vojtech@xxxxxxxx>: >> On Sun, Aug 12, 2018 at 12:26:20AM +0200, Rolf Fokkens wrote: >>> Hoi All, >>> >>> In 2013 I started using bcache-tools, and packaged bcache-tools for Fedora >>> (which meant changes to lvm2, util-linux packages for proper integration). >>> Although having been a happy user ever since, I missed the option to specify >>> specific parameters (sequential_cutoff, congested_read_threshold_us, etc) in >>> a very early stage during boot. My intention was to speedup the boot process >>> for my laptop, and this could best be done right before the root FS was >>> mounted from the initial ramdisk. >>> >>> My solution is here: https://github.com/g2p/bcache-tools/pull/20 >>> >>> Unfortunately the bcache-tools maintainer back then was not able to review, >>> so it got kind of stuck in the process. Being the maintainer of the Fedora >>> bcache-tools package nothing stopped me from including it anyway, and so I >>> did. And it did help me to speed up the boot process! >> >> I do agree a way of specifying these is needed, setting them from a >> script later during the boot process just doesn't cut it. >> >>> Although it works like a charm, there's one drawback: it pollutes the kernel >>> cmdline, which is limited in size. >>> >>> So now the community seems to be operational again, this might be good >>> moment to ask some feedback. I'd appreciate it if some of you would share >>> your thoughts on this: >>> >>> * Do you see an alternative for the kernel cmdline approach? >>> * Would it be useful in general to have more control over "volatile" >>> parameters like sequential_cutoff, congested_read_threshold_us, etc? >>> For example by means of a /etc/bcache.conf file? >> >> My preference would be to make all the parameters persistent, the same way >> other parameters are by storing them in the bcache device itself. >> >> I haven't explored how feasible it is and how future-proof (space for >> more, etc) and backwards-compatible (mount on old kernels) that can be >> made, though. > > Shouldn't udev rules be able to set these early during boot? It is one > of the first processes to start, and it can set sysfs attributes. > > I'm using these to set bcache device to rotational during early boot > so btrfs doesn't think it would be SSD: > >> kakra@jupiter /etc/udev/rules.d $ cat 00-ssd-scheduler.rules >> ACTION=="add|change", KERNEL=="bcache*", ATTR{queue/rotational}="1" >> ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{device/model}=="SD/MMC", ATTR{queue/rotational}="0" >> ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/iosched/slice_idle}="0" >> ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="kyber" >> ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq" > > It should be able to use e.g. ATTR{bcache/sequential_cutoff}="8M" to > set this value as soon as the device appears. > > > Regards, > Kai
