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. -- Vojtech Pavlik Director SUSE Labs
