From patchwork Wed Dec 31 18:30:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Mason X-Patchwork-Id: 5556101 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 62D389F2ED for ; Wed, 31 Dec 2014 18:31:09 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6F76820160 for ; Wed, 31 Dec 2014 18:31:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5D4D720154 for ; Wed, 31 Dec 2014 18:31:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751143AbaLaSac (ORCPT ); Wed, 31 Dec 2014 13:30:32 -0500 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:26879 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026AbaLaSab (ORCPT ); Wed, 31 Dec 2014 13:30:31 -0500 Received: from pps.filterd (m0004060 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id sBVIQDsF003781; Wed, 31 Dec 2014 10:30:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=facebook; bh=BuNtgGc4UGSTYVivbUX1n4Gws69X7Jmw+v4YHTaf4Ak=; b=FRrhKbgdusN3adr1KMeLBFUQmF1hmzkmnEMe5k0YoRrPVRHqgVshzkg/z+V6s+4FCC7r Tb8CuTWlHfjGQYGEP9r0GDR+R0gDRP4g8yL33nLMBmlsXTXS5vRWHIoku6SZZVc1NrCq Pyonyn9+qRug0tlPVIbNDu1HgRHby6zF8q8= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 1rmpaug2c6-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 31 Dec 2014 10:30:18 -0800 Received: from localhost (192.168.16.4) by mail.thefacebook.com (192.168.16.23) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 31 Dec 2014 10:30:15 -0800 Date: Wed, 31 Dec 2014 13:30:13 -0500 From: Chris Mason To: Qu Wenruo CC: Roman Mamedov , Marc MERLIN , Btrfs BTRFS Subject: [PATCH] Btrfs: don't delay inode ref updates during log replay Message-ID: <20141231183013.GA3637@ret.masoncoding.com> Mail-Followup-To: Chris Mason , Qu Wenruo , Roman Mamedov , Marc MERLIN , Btrfs BTRFS References: <20141228192614.GO17254@merlins.org> <20141229010047.7f9b6d43@natsu> <54A1FAB2.2050805@cn.fujitsu.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54A1FAB2.2050805@cn.fujitsu.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [192.168.16.4] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-31_07:2014-12-30, 2014-12-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.925924926977281 urlsuspect_oldscore=0.925924926977281 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=64355 rbsscore=0.925924926977281 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412310176 X-FB-Internal: deliver Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Commit 1d52c78afbb (Btrfs: try not to ENOSPC on log replay) added a check to skip delayed inode updates during log replay because it confuses the enospc code. But the delayed processing will end up skipping delayed refs from log replay because the inode itself wasn't put through the delayed code. This can end up triggering a warning at commit time: WARNING: CPU: 2 PID: 778 at fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty+0x32/0x34() Which is repeated for each commit because we never process the delayed ref. The fix used here is to change btrfs_delayed_delete_inode_ref to return an error if we're current in log replay. The caller will do the ref deletion immediately and everything will work properly. This bug can cause lost files, whick fsck will find. --repair on btrfs-progs 3.18 will fix them Signed-off-by: Chris Mason cc: stable@vger.kernel.org # v3.18 and any stable series that picked 1d52c78afbbf80b58299e076a159617d6b42fe3c Tested-By: Marc MERLIN --- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c index 054577b..de4e70f 100644 --- a/fs/btrfs/delayed-inode.c +++ b/fs/btrfs/delayed-inode.c @@ -1857,6 +1857,14 @@ int btrfs_delayed_delete_inode_ref(struct inode *inode) { struct btrfs_delayed_node *delayed_node; + /* + * we don't do delayed inode updates during log recovery because it + * leads to enospc problems. This means we also can't do + * delayed inode refs + */ + if (BTRFS_I(inode)->root->fs_info->log_root_recovering) + return -EAGAIN; + delayed_node = btrfs_get_or_create_delayed_node(inode); if (IS_ERR(delayed_node)) return PTR_ERR(delayed_node);