From patchwork Fri Feb 24 05:52:26 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 9589427 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 CA2A36042B for ; Fri, 24 Feb 2017 05:56:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BA04A28792 for ; Fri, 24 Feb 2017 05:56:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id ADB61287A2; Fri, 24 Feb 2017 05:56:18 +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.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI 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 AA09228792 for ; Fri, 24 Feb 2017 05:56:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750997AbdBXF4H (ORCPT ); Fri, 24 Feb 2017 00:56:07 -0500 Received: from cn.fujitsu.com ([59.151.112.132]:13082 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750937AbdBXF4G (ORCPT ); Fri, 24 Feb 2017 00:56:06 -0500 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="15915855" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 24 Feb 2017 13:52:51 +0800 Received: from G08CNEXCHPEKD01.g08.fujitsu.local (unknown [10.167.33.80]) by cn.fujitsu.com (Postfix) with ESMTP id 916DA47C4E9A; Fri, 24 Feb 2017 13:52:49 +0800 (CST) Received: from localhost.localdomain (10.167.226.34) by G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 24 Feb 2017 13:52:48 +0800 From: Qu Wenruo To: , Subject: [PATCH v2 3/9] btrfs-progs: convert: Add comment for the overall convert workflow Date: Fri, 24 Feb 2017 13:52:26 +0800 Message-ID: <20170224055232.4140-4-quwenruo@cn.fujitsu.com> X-Mailer: git-send-email 2.11.1 In-Reply-To: <20170224055232.4140-1-quwenruo@cn.fujitsu.com> References: <20170224055232.4140-1-quwenruo@cn.fujitsu.com> MIME-Version: 1.0 X-Originating-IP: [10.167.226.34] X-yoursite-MailScanner-ID: 916DA47C4E9A.A1145 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: quwenruo@cn.fujitsu.com 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 Convert is now a little complex due to that fact we need to separate meta and data chunks for different profiles. Add a comment with ascii art explaining the whole workflow and points out the really complex part, so any newcomers interested in convert can get a quick overview of it before digging into the hard to read code. Signed-off-by: Qu Wenruo --- convert/main.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/convert/main.c b/convert/main.c index 8d9f29fa..26356e8a 100644 --- a/convert/main.c +++ b/convert/main.c @@ -16,6 +16,63 @@ * Boston, MA 021110-1307, USA. */ +/* + * btrfs convert design: + * The overall design of btrfs convert is like the following: + * |<------------------Old fs----------------------------->| + * |<- used ->| |<- used ->| |<- used ->| + * || + * \/ + * |<---------------Btrfs fs------------------------------>| + * |<- Old data chunk ->|< new chunk (D/M/S)>|<- ODC ->| + * |<-Old-FE->| |<-Old-FE->|<- Btrfs extents ->|<-Old-FE->| + * + * ODC = Old data chunk, btrfs chunks containing old fs data + * Mapped 1:1 (logical address == device offset) + * Old-FE = file extents points to old fs. + * + * So old fs used space is (mostly) kept as is, while btrfs will insert + * its chunk(Data/Meta/Sys) into large enough free space. + * In this way, we can create different profiles for meta/data for converted fs. + * + * The DIRTY work is, we must reserve and relocate 3 ranges for btrfs: + * [0, 1M), [btrfs_sb_offset(1), +64K), [btrfs_sb_offset(2), +64K) + * + * Most work are spent handling corner cases around these reserved ranges. + * + * Detailed workflow is: + * 1) Scan old fs used space and calculate data chunk layout + * 1.1) Scan old fs + * We can a map of used space of old fs + * + * 1.2) Calculate data chunk layout <<< Complex work + * New data chunks must meet 3 conditions using result fomr 1.1) + * a. Large enough to be a chunk + * b. Doesn't cover reserved ranges + * c. Covers all the remaining old fs used space + * + * XXX: This can be simplified if we don't need to handle backup supers + * + * 1.3) Calculate usable space for btrfs new chunks + * Btrfs chunk usable space must meet 3 conditions using result from 1.2) + * a. Large enough to be a chunk + * b. Doesn't cover reserved ranges + * c. Doesn't cover any data chunks in 1.1) + * + * 2) Create basic btrfs + * Initial metadata and sys chunks are inserted in the first availabe + * space of result of 1.3) + * Then insert all data chunks into the basic btrfs + * + * 3) Create convert image + * We need to relocate reserved ranges here. + * After this step, the convert image is done, and we can use the image + * as reflink source to create old files + * + * 4) Iterate old fs to create files + * We just reflink any offset in old fs to new file extents + */ + #include "kerncompat.h" #include @@ -276,6 +333,9 @@ static void init_blk_iterate_data(struct blk_iterate_data *data, * The special point is, old disk_block can point to a reserved range. * So here, we don't use disk_block directly but search convert_root * to get the real disk_bytenr. + * + * XXX: Better extract this function as btrfs_reflink(), as in fact we are + * just reflinking from convert_image. */ static int record_file_blocks(struct blk_iterate_data *data, u64 file_block, u64 disk_block, u64 num_blocks)