On Mon, 23 May 2022, Coly Li wrote: > On 5/18/22 9:22 AM, Eric Wheeler wrote: > > Some time ago you ordered an an SSD to test the 4k cache issue, has that > > been fixed? I've kept an eye out for the patch but not sure if it was > > released. > > Yes, I got the Intel P3700 PCIe SSD to fix the 4Kn unaligned I/O issue > (borrowed from a hardware vendor). The new situation is, current kernel does > the sector size alignment checking quite earlier in bio layer, if the LBA is > not sector size aligned, it is rejected in the bio code, and the underlying > driver doesn't have chance to see the bio anymore. So for now, the unaligned > LBA for 4Kn device cannot reach bcache code, that's to say, the original > reported condition won't happen now. The issue is not with unaligned 4k IOs hitting /dev/bcache0 because you are right, the bio layer will reject those before even getting to bcache: The issue is that the bcache cache metadata sometimes makes metadata or journal requests from _inside_ bcache that are not 4k aligned. When this happens the bio layer rejects the request from bcache (not from whatever is above bcache). Correct me if I misunderstood what you meant here, maybe it really was fixed. Here is your response from that old thread that pointed at unaligned key access where you said "Wow, the above lines are very informative, thanks!" bcache: check_4k_alignment() KEY_OFFSET(&w->key) is not 4KB aligned: 15725385535 https://www.spinics.net/lists/linux-bcache/msg06076.html In that thread Kent sent a quick top-post asking "have you checked extent merging?" https://www.spinics.net/lists/linux-bcache/msg06077.html > And after this observation, I stopped my investigation on the unaligned sector > size I/O on 4Kn device, and returned the P3700 PCIe SSD to the hardware > vendor. Hmm, sorry that it wasn't reproduced. I hope I'm wrong, but if bcache is generating the 4k-unaligned requests against the cache meta then this bug might still be floating around for "4Kn" cache users. -Eric
