Lucas Clemente Vella <lvella@xxxxxxxxx> schrieb: > Hi, I've updated my kernel from 3.13.0 to 3.16.0, but the new kernel > wouldn't boot (I belive because of my bcache setup). So I have updated > a little further to kernel 3.17.1, and now it boots, but I get the > following log messages: > > $ dmesg | grep bcache > [ 1.156474] bcache: error on 585603df-7dd5-4d6f-a2ab-e80b59cc994d: > no journal entries found, disabling caching > [ 1.157393] bcache: register_cache() registered cache device sdb > [ 1.157464] bcache: register_bdev() registered backing device sda2 > [ 1.157598] bcache: register_bdev() registered backing device sda1 > [ 1.157695] bcache: cache_set_free() Cache set > 585603df-7dd5-4d6f-a2ab-e80b59cc994d unregistered > [ 1.239026] EXT4-fs (bcache1): mounted filesystem with ordered data > mode. Opts: (null) > [ 1.425166] bcache: bch_journal_replay() journal replay done, 788 > keys in 92 entries, seq 1095169 > [ 1.455283] bcache: bch_cached_dev_attach() Caching sda2 as bcache0 > on set 25497b90-14dd-4242-b35a-a15598492902 > [ 1.455317] bcache: register_cache() registered cache device sdb3 > [ 5.011443] EXT4-fs (bcache1): re-mounted. Opts: errors=remount-ro > [ 7.649948] EXT4-fs (bcache0): mounted filesystem with ordered data > mode. Opts: (null) > > This first message worries me, and I didn't had it before. Does it > means that the SSD caching is bypassed entirely? Was there any > incompatible changes between the two kernel versions? If so, how can I > safely reenable the caching? > > It seems weird that it is trying to sdb as cache device, because only > the partition sdb3 was formated as cache. Did you maybe first format sdb as bcache, then decided it would be better to partition it, then formatted sdb3? This could mean there's an orphan superblock lying around which is detected when bcache initializes. I once had a similar behavior where I formatted sdb as btrfs, then decided it would be better to have a GPT partition, and then formatted the partition. lsblk or blkid still showed me the wrong device (but also the partitioned one) and I decided to better use wipefs on the device and repartition again so this orphan superblock doesn't cause any havoc later. So, essentially the change between those kernel versions could be how bcache detects its devices. If this is the case and you are brave, you could find out which offset the superblock of bcache is at and destroy its superblock signature by changing a single byte of the raw sdb device with a hex editor. Just pay attention that it is not within some partition boundary which holds important data. You could also try to wipe sdb1 (write zeroes) after storing its data in a tar archive, when recreate its fs and restore from tar. If some orphan superblock is within the boundaries of sdb1, it would essentially be destroyed. If you are using modern partitioning, there's usually a gap before the first partition of 1 to 2 MBs which could also be wiped. But pay attention that boot loaders may have put payload into that gap. I'd check the output of blkid and lsblk from the old and new kernel first, best being done from a rescue system. Then compare the UUIDs of the detected partitions between old and new kernel. It should give an idea of what's gone wrong. -- Replies to list only preferred. -- 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
