Message ID | 20170125154325.GA13419@dhcp-amer-vpn-adc-anyconnect-10-154-187-238.vpn.oracle.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 01/25/2017 04:43 PM, Liu Bo wrote: > On Wed, Jan 25, 2017 at 10:31:32AM +0100, Marc Kleine-Budde wrote: >> Hello, >> >> I'm using debian's latest 4.9 Kernel on a 32bit armhf SMP board. The >> filesystem is in raid1 mode using two harddrives. After the system >> crashed (for yet unknown reason) the mounting of the raid1 failed >> with the following backtrace: > > Since this was happening at mount stage, it seems like our fs_root is > not set up yet, could you please try this debugging one? Since this is my production system, I've mounted the FS in the mean time on an amd64 (debian kernel v4.8.15-2) and it worked without problems. I'll try to compile a kernel with your patch for the affected systemm though. Marc
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index dcd2e79..11a3bf4 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4978,6 +4978,12 @@ static void btrfs_async_reclaim_metadata_space(struct work_struct *work) space_info = __find_space_info(fs_info, BTRFS_BLOCK_GROUP_METADATA); spin_lock(&space_info->lock); + if (!fs_info->fs_root) { + pr_info("BTRFS: fs_info->fs_root is not set up yet %s:%d\n", __func__, __LINE__); + WARN_ON(1); + spin_unlock(&space_info->lock); + return; + } to_reclaim = btrfs_calc_reclaim_metadata_size(fs_info->fs_root, space_info); if (!to_reclaim) {