On 2 Mar 2022, Coly Li verbalised: > On 2/23/22 8:26 PM, Zhang Zhen wrote: >> The reproduce opreation as follows: >> 1. mount a bcache disk with xfs >> >> /dev/bcache1 on /media/disk1 type xfs >> >> 2. run ls in background >> #!/bin/bash >> >> while true >> do >> echo 2 > /proc/sys/vm/drop_caches >> ls -R /media/disk1 > /dev/null >> done >> >> >> 3. remove cache disk sdc >> echo 1 >/sys/block/sdc/device/delete >> >> 4. dmesg should get xfs error >> >> I write a patch to improve，please help to review it, thanks. > > Hold on. Why do you think it should be fixed? As I said, it is as-designed behavior. I was thinking exactly as you were... but, y'know, this might be a genuine resiliency improvement, *if* done only when the cache is writearound (or none, I suppose!). Obviously if writes are being cached a cache device failure must trigger I/O failures visible to userspace... but if it's just speeding up the underlying device, having it fail would ideally just fail it out and cause all I/Os to proceed uncached, including the one that was underway when the cache I/O error was encountered. -- NULL && (void)
