On Tue, Aug 30, 2016 at 12:04 PM, Chris Murphy <li...@colorremedies.com> wrote:
> One of us would have to go look in source to see what causes "[ > 163.612313] BTRFS: failed to read the system array on sdd" to appear https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/btrfs/disk-io.c?id=refs/tags/v4.7.2 line 2864 And btrfs_read_sys_array is found here on 6587. So https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/btrfs/volumes.c?id=refs/tags/v4.7.2 And then comparing your 4.4.13 to 4.7.2.... https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/fs/btrfs/disk-io.c?id=v4.7.2&id2=v4.4.13 There are changes in these areas but looks like they're mainly printk's becoming btrfs_err. But I'd try a newer kernel before you give up on it. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/fs/btrfs/volumes.c?id=v4.7.2&id2=v4.4.13 More changes here too. I suggest using btrfs-progs 4.5.3 or 4.6.1. You could also try 4.7 but I'm getting some weird unexplained errors that only progs 4.7 complains about (clean scrubs, clean mounts, completely working file system, but a buncha backref complaints from 4.7's btrfs check). But I think the super-recover -v output should be reliable with any version in the last ~year. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
