From patchwork Tue May 17 11:24:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Lyakas X-Patchwork-Id: 9111591 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 4AF4DBF29F for ; Tue, 17 May 2016 11:25:39 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 20C6320279 for ; Tue, 17 May 2016 11:25:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0834D20218 for ; Tue, 17 May 2016 11:25:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752386AbcEQLZd (ORCPT ); Tue, 17 May 2016 07:25:33 -0400 Received: from mail-wm0-f47.google.com ([74.125.82.47]:35133 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792AbcEQLZc (ORCPT ); Tue, 17 May 2016 07:25:32 -0400 Received: by mail-wm0-f47.google.com with SMTP id e201so135534558wme.0 for ; Tue, 17 May 2016 04:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zadarastorage-com.20150623.gappssmtp.com; s=20150623; h=message-id:from:to:cc:subject:date:mime-version :content-transfer-encoding:importance; bh=cvaTosPZ/tlV3PBiqLFFr2MtuVvtz0RSqDr7lBnnals=; b=Nx21UcOG5nmJXCUcQYvtYDhgkMdi0im+cZ0xURdAOltSFRZLT+r+twmN++0phccNYM TFEqvVqo2np4AcKTS6E/U/PRW5AKVD3HbFXfninAixzFDc5RHTwY6aKWvGNSEHqgFhQ1 3xj2kyboRx9OuSHV7dP0imZzylKeZiUI7E2DI9w+T4CnjXjWPKywEWeHNkTF13x8BMCU rsCnSWW8QE05H0+ZTvKAhAxYwBWqKOXUfT0qKnUL21Np5bTPHe8CaZTxsvnkqzA9p0ys UV98+jFePkXOSTHg94NrFwnNf2S3ZL+FVQfwuFX138BLNzptNTWXJgs40smYqBXAecuL sYmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:subject:date:mime-version :content-transfer-encoding:importance; bh=cvaTosPZ/tlV3PBiqLFFr2MtuVvtz0RSqDr7lBnnals=; b=mCSDHLWQXC0Zqv9Nmb2Q6zdJ/T5+jw+z9Vq1d0i0SFMXMN7EMfkDBdEo8hmtMUeMsq P0UjB8hm+487unhQaP/CnNrEDJodkqs8Fv7yWYkInW2PhLMSQsmOJrXo0uRVxGF4JIwA sX9opZT9kuIJhNDP4UHfLFRgR4kDZ70aW17Gxh3axwbDN2Q2dE3+DGpF95kgGfh0FWSA QXQP7NK4lBBc2LB7QCgkiTjmCVo8H05lXdGCj4eb5WfPOQ2/pwcmTNJOZ3YvZEm17tv2 SGse0dCPy1vOxZywtc3SblPHsWSa0FT8slbDFQM5MNzxC3xDiOyBwOOfEtQZMpJD/OWy SEJg== X-Gm-Message-State: AOPr4FVSJ901W4R4jwDHejg0lkV7OfDpJ4otVswlBA0Bdt0kbGHR3JbxSHCwS+k38STRbw== X-Received: by 10.28.212.8 with SMTP id l8mr884527wmg.11.1463484331278; Tue, 17 May 2016 04:25:31 -0700 (PDT) Received: from alyakaslap ([95.173.32.19]) by smtp.gmail.com with ESMTPSA id y3sm2558766wji.40.2016.05.17.04.25.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 04:25:30 -0700 (PDT) Message-ID: <7AF66DC0FE0640D1A4E007C4DAC16AC4@alyakaslap> From: "Alex Lyakas" To: "linux-btrfs" Cc: "Ron Mandel" , "Yair Hershko" , "Shyam Kaushik" , "Lev Vainblat" , "Yaron Presente" Subject: [RCF - PATCH] btrfs: do not ignore errors from primary superblock Date: Tue, 17 May 2016 14:24:15 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,STOX_REPLY_TYPE, STOX_REPLY_TYPE_WITHOUT_QUOTES, T_DKIM_INVALID, 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 RFC: This patch not for merging, but only for review and discussion. When mounting, we consider only the primary superblock on each device. But when writing the superblocks, we might silently ignore errors from the primary superblock, if we succeeded to write secondary superblocks. In such case, the primary superblock was not updated properly, and if we crash at this point, later mount will use an out-of-date superblock. This patch changes the behavior to NOT IGNORING any errors on the primary superblock, and IGNORING any errors on secondary superblocks. This way, we always insist on having an up-to-date primary superblock. /* drop our reference */ @@ -3388,9 +3390,10 @@ static int write_dev_supers(struct btrfs_device *device, BTRFS_SUPER_INFO_SIZE); if (!bh) { btrfs_err(device->dev_root->fs_info, - "couldn't get super buffer head for bytenr %llu", - bytenr); - errors++; + "couldn't get super buffer head for bytenr %llu (sb copy %d)", + bytenr, i); + if (i == 0) + errors++; continue; } @@ -3413,10 +3416,10 @@ static int write_dev_supers(struct btrfs_device *device, ret = btrfsic_submit_bh(WRITE_FUA, bh); else ret = btrfsic_submit_bh(WRITE_SYNC, bh); - if (ret) + if (ret && i == 0) errors++; } - return errors < i ? 0 : -1; + return errors ? -1 : 0; } /* P.S.: when reviewing the code of write_dev_supers(), I also noticed that when wait==0 and we hit an error in one __getblk(), then the caller (write_all_supers) will not properly wait for submitted buffer-heads to complete, and we won't do the additional "brelse(bh);", which wait==0 case does. Is this a problem? --- 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/disk-io.c b/fs/btrfs/disk-io.c index 4e47849..0ae9f7c 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3357,11 +3357,13 @@ static int write_dev_supers(struct btrfs_device *device, bh = __find_get_block(device->bdev, bytenr / 4096, BTRFS_SUPER_INFO_SIZE); if (!bh) { - errors++; + /* we only care about primary superblock errors */ + if (i == 0) + errors++; continue; } wait_on_buffer(bh); - if (!buffer_uptodate(bh)) + if (!buffer_uptodate(bh) && i == 0) errors++;