Currently writing this from a Fedora 25 workstation boot-usb (with a pretty stable Wayland, so far), as my Arch system doesn't want to boot at the moment.

Where it began

So, where to begin? I first started using btrfs on my Thinkpad Twist. It had a (pretty mediocre) 128GB SSD. As you probably know, that's not a lot, especially if you like music.

So, now and then, it happened that my SSD was almost at 100% usage. When that happens, btrfs might get into trouble. Usually, a simple btrfs balance start -dusage=5 on your mounted partition will resolve the problem that you cannot write anything anymore. After that, you remove some stuff from your SSD (cleanup your overfull Downloads directory, or /tmp, or ~/.cache), and you're set for a month or two.

I also began using snapper, because being able to recover deleted, moved or altered files is pretty useful now and then. It keep regular btrfs snapshots, and decides on its own which ones to get rid of, and which ones to keep.

Now, those 128GB became a bit too cramped, partly due to using snapper, partly due to my love for vinyl FLAC, so I decided to invest in a 512GB mSATA SSD from Samsung. btrfs add device, et voila, we have a volume of 640GB! Doesn't matter if it one fails; I have backups for that.

But then my Thinkpad Twist died, and I got a Thinkpad X250. That one doesn't come with an mSATA slot, only with two M.2 slots. Long story short: delete a bunch of files using a USB 3.0 mSATA adapter, btrfs device remove the small SSD, put the mSATA in a SATA ↔ mSATA adapter, and work on.

This week, I came close again to my 100% usage. Snapper keeps a lot of stuff, apparently. So yesterday I thought, btrfs balance start, and everything will work out by today. But yesterday was different. Shortly after starting the balance, a kernel panic passed by, and I had to force shut down my laptop. It didn't mount the root partition upon reboot, so I decided to live boot.

Mounting on the Fedora 25 live USB took a night (a btrfs-transaction process was showing up in iotop and in regular top. btrfs check half an hour ago took around ten minutes, with errors like

root 13006 inode 10397953 errors 1, no inode item
       unresolved ref dir 150535 index 2188 namelen 14 name dukgo.com.save filetype 1 errors 5, no dir item, no inode ref

and now I'm trying to ls /.snapper, which spawns relocating block group 1991397605376 flags 1 in my dmesg. btrfs is continuing my rebalance though, so that could be a reason.

Let's just wait a bit, and hope this works out before this afternoon, as I have to work for a customer.

μSD cards

In October, I noticed that my (btrfs-formatted) micro SD card in my Jolla was mostly read-only, because of broken sectors. I used it to store my music (FLAC and opus), so no big deal. The 4GB microSD that was laying around would do for a train trip, I'd get my 10 year warranty and live on.

I formatted the 4GB card as btrfs, started copying music on it, and I got the exact same (leave sector numbers) errors in my kernel log. Seems like that one was broken too.

I got a 32GB card from the local IT-groceries for now. I formatted is as vfat. Let's see how long it takes now.

In the mean time, our Raspberry PI 2, which serves as Kodi media centre, locks up now and then. Seems like it's the micro SD card too, which is formatted as btrfs too; I could see "read-only filesystem" errors just before it locked down completely.

microSD cards and btrfs... Coincidence? It think not. I suspect that btrfs triggers too many writes for an SD card to handle.In the meanwhile, btrfs-transaction is still on top at 100% CPU usage, and on iotop at 1MB/s reading/writing. I'll have a shower and breakfast now, while my laptop tries to fix my filesystem.