On Thu, 6 Nov 2014 09:39:19 -0500, Josef Bacik wrote: > On 10/23/2014 04:44 AM, Miao Xie wrote: >> On Thu, 18 Sep 2014 11:27:17 -0400, Josef Bacik wrote: >>> Trying to reproduce a log enospc bug I hit a panic in the async reclaim code >>> during log replay. This is because we use fs_info->fs_root as our root for >>> shrinking and such. Technically we can use whatever root we want, but let's >>> just not allow async reclaim while we're doing log replay. Thanks, >> >> Why not move the code of fs_root initialization to the front of log replay? >> I think it is better than the fix way in this patch because the async >> reclaimer >> can help us do some work. >> > > Because this is simpler. We could move the initialization forward, but then > say somebody comes and adds some other dependency to the async reclaim stuff > in the future and doesn't think about log replay and suddenly some poor sap's > box panics on mount. Log replay is a known quantity, we don't have to worry > about enospc, so lets make it as simple as possible. Thanks,
Yes, you are right. So this patch looks good. Reviewed-by: Miao Xie <mi...@cn.fujitsu.com> -- 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
