On Tue, Aug 9, 2016 at 6:29 PM, Matt McKinnon <matt@xxxxxxxxxxxxxx> wrote: > Spoke too soon. Do I need to continue to run with that mount option in > place? It shouldn't be necessary. Something's still wrong for some reason, even with DUP metadata being CoW'd so someone else is going to have to speak up what the problem is. And that btrfs check not only doesn't come up clean but crashes suggests some confluence of things in kernel 4.3 and your hardware conspired to make the file system inconsistent in a way that isn't immediately recovering the usual way. That is, usebackuproots working suggests that there's a bug elsewhere in the storage stack because normally that shouldn't be necessary - something's happened out of order. 1 size 50.93TiB used 22.67TiB path /dev/sda1 What is the exact nature of this block device? If getting this back up and running is urgent I suggest inquiring on IRC what the next steps are. In the meantime I'd get a btrfs-image (which is probably going to be quite large given metadata is 60GiB), if that pukes then see if 'btrfs inspect-internal dump-tree /dev/sda1 > dumptree.log' which may also fail but before it fails might contain something useful. Obviously btrfs check shouldn't crash so that's a bug already. What do you get for free -m? It's known that btrfs check needs a lot of memory and pretty much all the metadata needs to be read in, so... if you have an SSD available it might make sense to setup a huge pile of swap on that SSD and rerun btrfs check. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
