How to revert bcache device to regular device
Asked Answered
R

3

10

I have a 20 gb SSD device on my laptop that i decided to try bcache on. It seemed to work, but for some time now, I've been getting an error on boot:

error on 0f3bbb55-6839-4ed6-8127-7976a969f726: corrupted btree at bucket 17571, block 483, 61 keys, disabling caching

I figure I could try and repair this, but I've decided I'm probably better off just disabling bcache - I don't know enough about this to risk losing data/hair if something breaks, and I think I'd be better off using the partition as swap for faster hibernating.

My question is, how do I safely stop using bcache on the device without reformatting the backing device?

I am using /dev/sda7 as my backing device, and /dev/sdb2 as the caching device (/dev/sdb1 is root).

If it matters, I'm running Ubuntu 14.04 with kernel 3.13.0-21-generic.

Update: I am essentially looking for a solution that reverts the changes made by make-bcache -B. FWIW, I ended up "solving" this by moving everything to a new partition and deleting the old (see comment below), but I'll leave this question up in case someone has an actual solution.

Roybn answered 2/4, 2014 at 18:54 Comment(0)
O
12

I had a time-sensitive issue with this recently and the following text saved my bacon:

D) Recovering data without bcache:

If bcache is not available in the kernel, a filesystem on the backing device is still available at an 8KiB offset. So either via a loopdev of the backing device created with --offset 8K, or any value defined by --data-offset when you originally formatted bcache with make-bcache.

For example: losetup -o 8192 /dev/loop0 /dev/your_bcache_backing_dev

From https://www.kernel.org/doc/Documentation/bcache.txt.

This has the added benefit of not modifying the partition table on the drive, so you can copy some data out and potentially remount it back to its original host.

Outward answered 6/7, 2017 at 13:37 Comment(0)
P
5

It's not very hard if you know the internals. I read from blocks to know that, in order to convert a normal partition to bcache, it shrinks a partition a little then add a bcache superblock there. So the partition data remains there. I did a test to find out the bcache superblock is 8192 bytes large:

for i in {1..20}; do dd if=my_bcache_device skip=$i | file -; done

So, to convert it back, just change the partition table so that it starts 8192 bytes later. With gdisk (or fdisk if you use MBR), delete the partition and then recreate it at the new place, and you're done :-) You can enlarge it later if you want (but I didn't try this).

Note that if your bcache is dirty (and you can't use it any more), you'll have to fsck your partition and mess with corrupted data. I had good luck that only a few files was corrupted after a manual fsck.

Pinup answered 14/5, 2016 at 12:47 Comment(0)
T
1

One solution is to detach the device from the cache, and use it in no cache or pass-through mode. To do this, run as root:

echo 1 > /sys/block/<device>/bcache/detach

(where <device> is the cache backing device, /dev/sda7 in your case).

This will detach the backing device from the cache, so that the cache is no longer used but the drive accessed directly for all reads and writes. If your cache wasn't in a corrupted state, this would also write back any dirty data from the cache back to the backing device; in your corrupted state you are probably out of luck, though.

You will still have to access the device through the /dev/bcache0/ interface, but no caching will be performed.

Telpher answered 25/4, 2014 at 14:8 Comment(1)
Thanks - I believe this is essentially the state the device was in - it mounted fine, and there seemed to be no errors. I was hoping to find a solution that essentially undid make-bcache -B. In the end, I went the brute force route: * resized the partition using the instructions here: wiki.archlinux.org/index.php/Bcache#Resize_backing_device * create new partition and copy all data from the backing partition to it * delete backing partition and resize new, non-bcache partition This took a long time, but it worked :)Roybn

© 2022 - 2024 — McMap. All rights reserved.