Hello! Am Di., 24. Sept. 2019 um 15:32 Uhr schrieb Marcelo RE <marcelo.re@xxxxxxxxx>: > I have set rootdelay=1,2,3,4,5 but it do not solve the problem. > I will see dracut to see if it works. Similar to my experience. That worked for a while but later it didn't because there was a bug in dracut. But that seems fixed now. I removed all my manual patches and it still works. If you set a debug breakpoint in dracut (kernel cmdline "rd.pre-mount=break"), then wait for a few seconds, and then resume dracut and it works from there, it's probably a timing issue. If it's still missing devices, you can try probing bcache from within the breakpoint and see if it then resumes properly. While in the breakpoint, you can also try manually mounting your rootfs to "/sysroot" and look for error messages. Don't forget to unmount before rebooting because dracut won't run any shutdown logic when rebooting from the breakpoint. > For the record, I use Kubuntu 19.04 in an Asus Strix GL702Z with a > 256GB SSD and 1TB HD. I have a 100GB SSD partition for the bcache. > With Kubuntu 16.04, the config with bcache was really fast. 9s to > start to login and 14s to start all the apps in the previous session > of KDE. Yes, back with earlier kernels, I had boot times to full desktop in under 30 seconds, with rootfs on bcache/btrfs. BTW: When I write "boot time" I always mean "... to the full desktop" in my following answers. > When I update, I jump to 18.04. I boot without problem and > intermediately update to 19.04 and in that moment the kernel change. > Now it take far more time to boot. Aprox 35s to login plus 20s to show > the desktop. I'm seeing this, too: Currently my boot times are at least twice as long, with a semi-cold bcache even more than a minute. But I'm not sure where we should look for the problem: Is it in bcache? Is it in btrfs? Is it somewhere else in the kernel layer? After all, a lot has changed in memory management, VFS, and drivers... The kernel has switched to multi-queue, old IO schedulers no longer exist... Additionally, I turned write-back caching off because I saw effects that under memory pressure bcache could loose writes to its journal without noticing it. Upon reboot it would fall over a transaction missing in the middle of the journal. Also, bcache write-back is sooo slow (only 4kb/s) that it has no chance of writing back all data to the disk because my system generates at least 4kb/s writes constantly (usually 8-12), so the cache is slowly piling up unwritten data. If something goes wrong, my FS on the backing device is potentially missing days over days of important metadata writes (because those mainly go through writeback) and it will be broken just beyond repair. I've semi-fixed it by bumping the minimum writeback rate to 4 MB/s but that feels wrong. Or the default is just way too low (it should be higher than the normal in-flow of a mostly-idle system which would write log data every once in a while, or updates access metadata). Maybe it should auto-tune itself somehow. 4 MB/s seemed reasonable to me as it should still allow good enough random access throughput even while this rate of writeback is enforced to the backing devices. But all in all, using bcache feels much less of an improvement to a desktop system than it did maybe 1-2 years ago. But again: I'm not sure if we can accuse bcache of that or other changes to the kernel (and btrfs in my case). Especially, low but constant throughput write-loads seem to make the system much more sluggish today than maybe 1-2 years ago. Regards, Kai > El mar., 24 sept. 2019 a las 9:37, Kai Krakow (<kai@xxxxxxxxxxx>) escribió: > > > > Hello! > > > > I was experiencing that, too. There may be a race in initramfs between > > the kernel enumerating the bcache devices and the scripts trying to > > figure out the filesystems. There's two ways around it: The > > distribution should fix the initramfs scripts to wait longer for > > rootfs device nodes to appear, or you could try adding rootdelay=5 to > > your kernel cmdline as a temporary workaround (this delays mounting > > for 5 seconds, you can try different values). > > > > I'm using dracut as initramfs generator and it seems fixed since a few > > versions. I don't think this is a bcache issue: initramfs needs to > > probe bcache, then the filesystems. It's more likely this is a udev > > issue. > > > > Regards, > > Kai > > > > Am Di., 24. Sept. 2019 um 10:40 Uhr schrieb Coly Li <colyli@xxxxxxx>: > > > > > > On 2019/9/24 1:33 上午, Marcelo RE wrote: > > > > Hi. > > > > > > > > have problems running bcache with the kernel 5.x in KUbuntu. It work > > > > fine with kernel 4.x but fail to start with 5.x. Currently using 5.2.3 > > > > (linux-image-unsigned-5.2.3-050203-generic). > > > > When power on the laptop, sometimes it start to busybox and sometime > > > > it boot fine. > > > > If boot to busybox, I just enter reboot until it starts correctly. > > > > I tested: > > > > linux-image-4.15.0-29-generic > > > > linux-image-4.15.0-34-generic > > > > linux-image-5.0.0-20-generic > > > > linux-image-5.0.0-21-generic > > > > linux-image-5.0.0-23-generic > > > > linux-image-5.0.0-25-generic > > > > linux-image-5.0.0-27-generic > > > > linux-image-5.0.0-29-generic > > > > linux-image-unsigned-5.2.3-050203-generic > > > > > > > > What can be done? > > > > > > It is not easy to locate the problem by kernel versions. There are quite > > > a lot fixes since 4.15 to 5.2. > > > > > > If there is any more information or clue, maybe I can help to guess. > > > > > > -- > > > > > > Coly Li
