On Sat, Apr 11, 2015 at 4:09 PM, Kai Krakow <hurikhan77@xxxxxxxxx> wrote: > With this knowledge, I guess that bcache could probably detect its backing > device signature twice - once through the underlying raw device and once > through the md device. From your logs I'm not sure if they were complete It doesn't, the system is smarter than you think it is. > enough to see that case. But to be sure I'd modify the udev rules to exclude > the md parent devices from being run through probe-bcache. Otherwise all > sorts of strange things may happen (like one process accessing the backing > device through md, while bcache access it through the parent device - > probably even on different mirror stripes). This didn't occur, I copied all the lines pertaining to bcache but skipped the superfluous ones. > It's your setup, but personally I'd avoid MD for that reason and go with > lvm. MD is just not modern, neither appropriate for modern system setups. It > should really be just there for legacy setups and migration paths. Not related to bcache at all. Perhaps complain about MD on the appropriate list? I'm not seeing any evidence that MD had anything to do with this, especially since the issues with bcache are entirely confined to the direct SATA access to /dev/sda4. In that vein, I'm reading the on-disk format of bcache and seeing exactly what's still valid on my system. It looks like I've got 65,000 good buckets before the first bad one. My idea is to go through, look for valid data in the buckets and use a COW in user-mode-linux to write that data back to the (copy-on-write version of) the backing device. Basically, anything that passes checksum and is still 'dirty', force-write-it-out. Then see what the status of my backing-store is. If it works, do it outside UML to the real backing store. Are there any diagnostic tools outside the bcache-tools repo? Not much there other than show the superblock info. Otherwise I'll just finish writing it myself. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
