On 13 Oct 2017, Michael Lyle said: > On 10/13/2017 12:59 AM, Alexandr Kuznetsov wrote: >> I thought that lvm is old, mature and safe technology, but here it is >> stuck, then manualy interrupted and result is catastrophic data corruption. >> lvm sits on top of that sandwich of block devices, on layer of >> /dev/bcache* devices. Another question here is how crazy lvm could >> damage data outside of /dev/bcache* devices? This means that some >> necessary io buffer range checks are missing inside bcache. > > I don't know what commands you ran. I've never seen/heard of a bcache > superblock corrupted, and I believe the mappings/shrink are appropriate. I have also had corruption on a writethrough bcache (atop RAID-6, with LVM PVs within it) causing (rootfs) mount failure: bucket corruption, IIRC. Every time I rebooted I got warnings that bcache couldn't clean up in time, and I suspect this caused corruption in the end (fairly fast, actually, less than a month after starting using bcache: it had only just finished populating). The thing is in none mode at the moment, waiting for me to revamp my shutdown process to rotate the initramfs into place at shutdown so I can unmount the rootfs and stop the bcache, in the hope that that might give it a chance to shut down neatly. (Even so, finding that dirty shutdown can corrupt the bcache is unpleasant. I guess nobody does powerfail tests? How do most people shut down their bcache-on-rootfs systems?) -- NULL && (void) -- 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
