> Interesting; it does indeed have a stale header of some kind: > > zpalmer@thirtyseven:~$ sudo blkid /dev/sda7 > /dev/sda7: UUID="b56e8430-2594-436a-9fba-b91617cdaa5e" TYPE="crypto_LUKS" > zpalmer@thirtyseven:~$ sudo /sbin/wipefs /dev/sda7 > offset type > ---------------------------------------------------------------- > 0x0 crypto_LUKS [crypto] > UUID: b56e8430-2594-436a-9fba-b91617cdaa5e > > But /dev/sda7 is a bcache backing volume. > > zpalmer@thirtyseven:~$ sudo probe-bcache /dev/sda7 > 4b6ead1d-3341-407c-9e16-dd9e639268e4: UUID="" TYPE="bcache" > > Doesn't bcache put its superblock in the first part of the block > device? How is it possible that the device looks like a bcache > backing volume and a LUKS encrypted volume at the same time? (For the > record, I know that the LUKS volume identified above is the stale > one; when I used LVM to move everything around, I created a fresh > LUKS encrypted volume which has a different UUID than the old one > shown above.) > > Thanks, The first 4k of the device weren't erased; the bcache superblock comes after that. Fixed now. You can erase with wipefs -a, and do the same look/erase thing on /dev/sdb3. I'm on bcache-for-3.11 which doesn't have shutdown issues. I see your kernel is based on stable kernel 3.10.4, which backports a fix for #715019. I'd consider the suspend issue a separate one. -- 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
