> 2023年1月26日 19:30，Andrea Tomassetti <andrea.tomassetti-opensource@xxxxxxxx> 写道： > > Hi, > I know that bcache doesn't natively support multi-level caching but I > was playing with it and found this interesting "workaround": > make-bcache -B /dev/vdb -C /dev/vdc > the above command will generate a /dev/bcache0 device that we can now > use as backing (or cached) device: > make-bcache -B /dev/bcache0 -C /dev/vdd > This will make the kernel panic because the driver is trying to create > a duplicated "bcache" folder under /sys/block/bcache0/ . > So, simply patching the code inside register_bdev to create a folder > "bcache2" if "bcache" already exists does the trick. > Now I have: > vdb 252:16 0 5G 0 disk > └─bcache0 251:0 0 5G 0 disk > └─bcache1 251:128 0 5G 0 disk /mnt/bcache1 > vdc 252:32 0 10G 0 disk > └─bcache0 251:0 0 5G 0 disk > └─bcache1 251:128 0 5G 0 disk /mnt/bcache1 > vdd 252:48 0 5G 0 disk > └─bcache1 251:128 0 5G 0 disk /mnt/bcache1 > > Is anyone using this functionality? I assume not, because by default > it doesn't work. > Is there any good reason why this doesn't work by default? > > I tried to understand how data will be read out of /dev/bcache1: will > the /dev/vdd cache, secondly created cache device, be interrogated > first and then will it be the turn of /dev/vdc ? > Meaning: can we consider that now the layer structure is > > vdd > └─vdc > └─bcache0 > └─bcache1 > ? IIRC, there was a patch tried to achieve similar purpose. I was not supportive for this idea because I didn’t see really useful use case. In general, extra layer cache means extra latency in the I/O path. What I see in practical deployments are, people try very hard to minimize the cache layer and place it close to application. Introduce stackable bcache for itself may work, but I don’t see real usage yet, and no motivation to maintain such usage still. Thanks. Coly Li
