bcache seems to work fine, but after rebooting, the ext4 filesystem stored in
/dev/bcache0 frequently, but not always, becomes corrupted - seemingly, it only damages metadata for recently modified files (after
e2fsck -y finished, I found in /lost+found a lot of files from my browser cache, some file lists from recently installed packages, etc.) Any idea what was causing the corruption or how to use bcache without encountering it again?
- I installed Ubuntu 14.04 and Windows 8.1 to a 1TB HDD.
- I later added a 64GB SSD.
- My first attempts to install
blocksto convert my root partition failed because it depends on Python 3.3, while Ubuntu 14.04 only packages Python 3.4.
- I rebooted into Windows to look into enabling Intel Smart Response (the Windows equivalent of bcache), rebooted to switch the SATA mode from AHCI to RAID (because that's the only way Smart Response can be enabled), booted Windows again and enabled Smart Response to use ~18.6GB of the SSD as cache.
- I booted Ubuntu and discovered that the disk partitions used by Windows/Smart Response were not visible.
- After some investigation, I discovered that Smart Response, rather that just using disk partitions, had created a fake RAID array, splitting the SSD into two parts.
- I installed
mdadmand was able to see the two parts of the SSD under Ubuntu.
- I used
make-bcache -Cto create a cache on the rest of the SSD.
- I booted into Windows again, only to discover that Smart Response was no longer enabled and the RAID array seemed to have disappeared
- After a lot of work, I forced
python3-blocksand its dependencies to install despite the Python version mismatch (it seems that Python 3.4 is almost completely backwards compatible with Python 3.3). With a bit more work, I attempted to use
blocks to-bcache --maintboot /dev/sda8 --join some-uuid-that-looks-like-thisto convert my root partition to a bcache backing device. It rebooted, but when the system resumed, it was still using
/dev/sda8directly, the conversion hadn't happened.
- I put the Ubuntu installer image on a USB stick and booted from it
- I moved /boot from the HDD to the SSD.
- I installed Python 3.3 from the deadsnakes PPA, then forced
python3-blocksand dependencies to install as before.
- I modified
_ped = imp.load_dynamic('_ped', '/usr/lib/.../_ped.something.so')instead of
import _pedto load pyparted because it couldn't find it for reasons that I don't understand
- I successfully ran
blocks to-bcache /dev/sda8 --join some-uuid-that-looks-like-this
- I helped Grub find /boot, then booted into Ubuntu, now with
/dev/bcache0mounted as the root partition, and regenerated grub's config.
- I successfully rebooted into the (now much faster) Ubuntu install. I rebooted several more times just to admire how fast it was. No signs of trouble.
- I turned on the computer the next morning and it booted, but found that Chrome wouldn't open because it couldn't get a lock to prevent user profile corruption, which in turn was due to the fact that the root partition had been automatically remounted read-only after an ext4 error (it was mounted originally with
- I rebooted, and now found that the kernel couldn't find the root partition by its UUID. Running blkid on /dev/bcache0 confirmed that its UUID was not to be found.
- I rebooted to the USB stick, and ran
e2fsck -f -yrepeatedly until it came up clean. The first time it couldn't even find the superblock and I had to follow its suggestion to specify an alternate superblock location.
- I rebooted to Ubuntu running on bcache - it seemed to work fine.
- I reinstalled all of the installed packages one by one with
apt-get --reinstallto guard against later trouble caused by corrupted or lost files.
- After the package reinstallation completed, I followed its request to reboot.
- Upon booting, it again experienced ext4 errors. I ran
e2fsck -yand rebooted.
- Everything seemed fine again, but I had no idea what kept causing the corruption. I resized the Windows partition, created a new ext4 partition, and copied /home and /root into the new partition.
- I deleted the partitions that I had used as cache and backing device and did a clean install of Ubuntu with /boot and / on the SSD and /home on the HDD.
- I restored my data from the backup partition onto the new /home and resized the Windows partition back to its original size.
- No problems since.
Throughout all of this, the SMART self-tests on both SSD and HDD claimed that they were passing.