On Sat, Mar 16, 2019 at 3:35 AM Luis Panadero Guardeño <luis.panadero@xxxxxxxxx> wrote: > > > [ 3490.976048] BTRFS: error (device sdc2) in btrfs_run_delayed_refs:3083: errno=-17 Object already exists > > [ 3490.976062] BTRFS: error (device sdc2) in btrfs_replay_log:2308: errno=-17 Object already exists (Failed to recover log tree) It's a problem with log replay. That you're stuck here means it's a bug, but I can't tell you where. It might have started days or weeks earlier and cumulatively ended up here where the kernel can't deal with it; or maybe it's an SSD firmware bug; or maybe some of both. Also, when Btrfs goes read only it's trying to avoid causing more corruption, but it might have already been too late. Anyway, you can see if it will mount with a newer kernel, try the newest you can from 4.19 or 4.20 series. Another possibility that will come with some data loss is `btrfs rescue zero-log /dev/` which will zero the log tree, and whatever writes were happening at the time the log tree was being written to will be lost - up to 30 seconds worth from before going read-only. So if you can live with that you can try it. The big problem with 4.16 series is it's not long term so it's EOL and not getting any bug fixes. Ideally run the newest stable kernel. Also, the crash with btrfs check is a bug in btrfs-progs 4.15. I'm pretty sure it's fixed, but you can update btrfs-progs to 4.20.2 to find out. I don't know any distro doing backports, so it's reasonable to just use the latest upstream version once it's a couple weeks old. For the purpose of zeroing the log, I don't think you need to update btrfs-progs. -- Chris Murphy
