> 2024年11月19日 12:19，liequan che <liequanche@xxxxxxxxx> 写道： > [snipped] >>> 7. Repartition again, triggering kernel panic again. >>> parted -s --align optimal /dev/nvme2n1 mkpart primary 2048s 1536GiB >>> The same operation was performed on the other two servers, and no >>> panic was triggered. > >> I guess this is another undefine operation. I assume the cache device is still references somewhere. A reboot should follow the wipefs. > Your guess is correct. In addition, after erasing the superblock > information in CD rescue mode, > I rebooted into the system where the original panic kernel was located. > Please try latest upstream kernel and try whether you can see the issue. c->root is allocated by __bch_btree_node_alloc(), it doesn’t return NULL pointer. Your kernel is 5.10 based distribution kernel, I am not able to help much here. If you may reproduce the oops in latest upstream kernel, it will be a surprise and please let me know. >>> The server with the problem was able to enter the system normally >>> after the root of the cache_set structure was determined to be empty. >>> I updated the description of the problem in the link below. > >> No, if you clean up the partition, no cache device will exist. Cache registration won’t treat it as a bcache device. > >> OK, from the above description, I see you replace the backing device (and I don’t know where the previous data was), then you extend the cache device size. They are all unsupported operations. > The behavior here is a bit strange. After partitioning, I may have > recreated the bcache device here, > which triggered the bcache rigister operation. Then the kernel panicked again. When you mention your operations, it is better to provide exact detailed command lines, otherwise maybe I will misunderstand you. After all, please try the latest upstream kernel. Not the distro kernel. Otherwise I am not able to help. Coly Li
