From patchwork Mon Mar 26 08:27:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anand Jain X-Patchwork-Id: 10307357 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 62F14600CC for ; Mon, 26 Mar 2018 08:26:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4B3C029502 for ; Mon, 26 Mar 2018 08:26:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3F9DB295B0; Mon, 26 Mar 2018 08:26:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8BC3529502 for ; Mon, 26 Mar 2018 08:26:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752163AbeCZI0K (ORCPT ); Mon, 26 Mar 2018 04:26:10 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:41244 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752166AbeCZI0E (ORCPT ); Mon, 26 Mar 2018 04:26:04 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2Q8JLX3039581 for ; Mon, 26 Mar 2018 08:26:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : in-reply-to : references; s=corp-2017-10-26; bh=XfTF+I1W79JOLc3pevMCNyXD2K2ZEipG3lBO31XAAoA=; b=IlWT9vP0wpWky8YLU/HslZgy+W7S/ZKg5QY+xuJvzyyGiBedSpUGlwYWXKbYdpg3tdvh AVkzdjNd1PzuyW6H8P/QMqkTMnalUWlxo/+7ESlXIbxYG/JUAFBQcOLpbARXzpIKaDnb b4ZPYo8y+5/J6qoS1CwcBajJO/E7dIhZZ+C1Ea6+CitzB9juB+67O6LLE7JPekSW0ueL m+1whnpvZQYUEqnSpC4uf66AAH8hhupbNB8pSUGAW/mtpNX9z7KW8y0P+XxND/ujiVG/ Q81y8aFKHy0VRkq7wClW3+gtCpaTncKaPrnHJL7bW70SZyv+QnGYC9Vn8xSjpeIfPO+4 hg== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2gxw8gg0rj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 26 Mar 2018 08:26:03 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2Q8Q21f022249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 26 Mar 2018 08:26:03 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2Q8Q25o024025 for ; Mon, 26 Mar 2018 08:26:02 GMT Received: from tp.sg.oracle.com (/10.186.53.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Mar 2018 01:26:01 -0700 From: Anand Jain To: linux-btrfs@vger.kernel.org Subject: [PATCH] btrfs-progs: wipe copies of the stale superblock beyond -b size Date: Mon, 26 Mar 2018 16:27:42 +0800 Message-Id: <20180326082742.9235-10-anand.jain@oracle.com> X-Mailer: git-send-email 2.15.0 In-Reply-To: <20180326082742.9235-1-anand.jain@oracle.com> References: <20180326082742.9235-1-anand.jain@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8843 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803260088 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP During the mkfs.btrfs -b btrfs_prepare_device() zeros all the superblock bytenr locations only if the bytenr is below the blockcount. The problem with this is that if the BTRFS is recreated with a smaller size then we will leave the stale superblock in the disk which shall confuse the recovery. As shown in the test case below. mkfs.btrfs -qf /dev/mapper/vg-lv mkfs.btrfs -qf -b1G /dev/mapper/vg-lv btrfs in dump-super -a /dev/mapper/vg-lv | grep '.fsid|superblock:' superblock: bytenr=65536, device=/dev/mapper/vg-lv dev_item.fsid ebc67d01-7fc5-43f0-90b4-d1925002551e [match] superblock: bytenr=67108864, device=/dev/mapper/vg-lv dev_item.fsid ebc67d01-7fc5-43f0-90b4-d1925002551e [match] superblock: bytenr=274877906944, device=/dev/mapper/vg-lv dev_item.fsid b97a9206-593b-4933-a424-c6a6ee23fe7c [match] So if we find a valid superblock zero it even if it's beyond the blockcount. Signed-off-by: Anand Jain --- utils.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/utils.c b/utils.c index e9cb3a82fda6..6a9408b06e73 100644 --- a/utils.c +++ b/utils.c @@ -365,6 +365,41 @@ int btrfs_prepare_device(int fd, const char *file, u64 *block_count_ret, return 1; } + /* + * Check for the BTRFS SB copies up until btrfs_device_size() and zero + * it. So that kernel (or user for the manual recovery) don't have to + * confuse with the stale SB copy during recovery. + */ + if (block_count != btrfs_device_size(fd, &st)) { + for (i = 1; i < BTRFS_SUPER_MIRROR_MAX; i++) { + struct btrfs_super_block *disk_super; + char buf[BTRFS_SUPER_INFO_SIZE]; + disk_super = (struct btrfs_super_block *)buf; + + /* Already zeroed above */ + if (btrfs_sb_offset(i) < block_count) + continue; + + /* Beyond actual disk size */ + if (btrfs_sb_offset(i) >= btrfs_device_size(fd, &st)) + continue; + + /* Does not contain any stale SB */ + if (btrfs_read_dev_super(fd, disk_super, + btrfs_sb_offset(i), 0)) + continue; + + ret = zero_dev_clamped(fd, btrfs_sb_offset(i), + BTRFS_SUPER_INFO_SIZE, + btrfs_device_size(fd, &st)); + if (ret < 0) { + error("failed to zero device '%s' bytenr %llu: %s", + file, btrfs_sb_offset(i), strerror(-ret)); + return 1; + } + } + } + *block_count_ret = block_count; return 0; }