Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1862123rwb; Fri, 19 Aug 2022 10:36:58 -0700 (PDT) X-Google-Smtp-Source: AA6agR4JMmSpSGEMXxXk9FC27is/qfgdtQUdeMqvlt90nBD4O9oPrzixWJ9L9hLeF3W5WI0RFrx5 X-Received: by 2002:a17:90b:180f:b0:1f5:160c:a656 with SMTP id lw15-20020a17090b180f00b001f5160ca656mr15591134pjb.193.1660930617952; Fri, 19 Aug 2022 10:36:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660930617; cv=none; d=google.com; s=arc-20160816; b=EcjiveCNlC4xrklgmKpkuO1qNAQ+VKO5qTgj4aTsx4xsQVUBU/AoVyh1ulhQj+9g0d EFG+ppITFDFB1zav7iTggL4GXcMQ+wo3yUnm+o38E/PBWW/1N1JJy1xQ67sAnBEgpnbf 8R188Aa9LGP6F9/am9t4dJ8ALgGN90EAVy9VjgDJtW+ziPMPUyAo5py0qMz0Bl6tq+Ni ixnLMHlicjBVpKxZXBvmmBwUT2AFhJx4D4Aam41ppewp+djBe5GRLc8G4yL+UejS47gu igxMFQS/5wdRNWcjDuXh53NgxdjF/0zxWtxpZB0IbYirf7hB8PRiLdyyKsY6vzCr98kV sBVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=iT6EiPrR87e+jHfvmLhUPNaQylZfhdZ3PRzpqaOpnA0=; b=jjroIOlCddZllvAkjE0U331L3CbduMXH1V/5eg+C4ehRQJjaz2CmD90og01Pm6YSZf KrNQHUmzrbD3C+AT4mf+j0HMZIDIax0MDhDd1Dkd9DWxN86V3rPdtTNZZZXo2AvKCL3w sHd7fx+BDvjsUyIOx7eYqN/X5sFWcfMF3/zEdVVapqrlySH35pFCgQD1l8+CrebKjVKE DC00FJLGcBWvmFUsU6zpdENjQWe3Vv+pTwhGiN57UEhASg+l309b+O+mr5iXACOFMo2B crebe53LnHADg+w1vDEL0aI6WIJQJlwgPAzTW+GSZtvfgBiwQphUut4or/lq8bnl+Tf8 EWzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=BArwLuTz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b3-20020a63d803000000b003f5f3fc0d1fsi4350543pgh.57.2022.08.19.10.36.46; Fri, 19 Aug 2022 10:36:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=BArwLuTz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354469AbiHSQy0 (ORCPT + 99 others); Fri, 19 Aug 2022 12:54:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354364AbiHSQwv (ORCPT ); Fri, 19 Aug 2022 12:52:51 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C888F115225; Fri, 19 Aug 2022 09:15:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id ADA7461811; Fri, 19 Aug 2022 16:13:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD9EEC433D6; Fri, 19 Aug 2022 16:13:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660925631; bh=q3MQfzVcYa2SMCIeCHXdM1GJsNXSe7BTAjl3NOeM76I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BArwLuTz/lm/KHhMYDROeYnSEJWEbRzTW+lnSbRBQhvRtVyQxXuaD0Qd0hN/Euuft XhR8MOthoHtN7kQFCf3lEJNrnLcenDhgi8b8pvdKq/5ziZI1/BLnLD26cvfdGRkL69 EX2zlUbcQhyNsvCK90JquKsSenZCUYMONCgIYCes= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Sterba , Qu Wenruo Subject: [PATCH 5.10 544/545] btrfs: only write the sectors in the vertical stripe which has data stripes Date: Fri, 19 Aug 2022 17:45:14 +0200 Message-Id: <20220819153853.952358483@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220819153829.135562864@linuxfoundation.org> References: <20220819153829.135562864@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Qu Wenruo commit bd8f7e627703ca5707833d623efcd43f104c7b3f upstream. If we have only 8K partial write at the beginning of a full RAID56 stripe, we will write the following contents: 0 8K 32K 64K Disk 1 (data): |XX| | | Disk 2 (data): | | | Disk 3 (parity): |XXXXXXXXXXXXXXX|XXXXXXXXXXXXXXX| |X| means the sector will be written back to disk. Note that, although we won't write any sectors from disk 2, but we will write the full 64KiB of parity to disk. This behavior is fine for now, but not for the future (especially for RAID56J, as we waste quite some space to journal the unused parity stripes). So here we will also utilize the btrfs_raid_bio::dbitmap, anytime we queue a higher level bio into an rbio, we will update rbio::dbitmap to indicate which vertical stripes we need to writeback. And at finish_rmw(), we also check dbitmap to see if we need to write any sector in the vertical stripe. So after the patch, above example will only lead to the following writeback pattern: 0 8K 32K 64K Disk 1 (data): |XX| | | Disk 2 (data): | | | Disk 3 (parity): |XX| | | Acked-by: David Sterba Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/raid56.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 51 insertions(+), 4 deletions(-) --- a/fs/btrfs/raid56.c +++ b/fs/btrfs/raid56.c @@ -332,6 +332,9 @@ static void merge_rbio(struct btrfs_raid { bio_list_merge(&dest->bio_list, &victim->bio_list); dest->bio_list_bytes += victim->bio_list_bytes; + /* Also inherit the bitmaps from @victim. */ + bitmap_or(dest->dbitmap, victim->dbitmap, dest->dbitmap, + dest->stripe_npages); dest->generic_bio_cnt += victim->generic_bio_cnt; bio_list_init(&victim->bio_list); } @@ -874,6 +877,12 @@ static void rbio_orig_end_io(struct btrf if (rbio->generic_bio_cnt) btrfs_bio_counter_sub(rbio->fs_info, rbio->generic_bio_cnt); + /* + * Clear the data bitmap, as the rbio may be cached for later usage. + * do this before before unlock_stripe() so there will be no new bio + * for this bio. + */ + bitmap_clear(rbio->dbitmap, 0, rbio->stripe_npages); /* * At this moment, rbio->bio_list is empty, however since rbio does not @@ -1207,6 +1216,9 @@ static noinline void finish_rmw(struct b else BUG(); + /* We should have at least one data sector. */ + ASSERT(bitmap_weight(rbio->dbitmap, rbio->stripe_npages)); + /* at this point we either have a full stripe, * or we've read the full stripe from the drive. * recalculate the parity and write the new results. @@ -1280,6 +1292,11 @@ static noinline void finish_rmw(struct b for (stripe = 0; stripe < rbio->real_stripes; stripe++) { for (pagenr = 0; pagenr < rbio->stripe_npages; pagenr++) { struct page *page; + + /* This vertical stripe has no data, skip it. */ + if (!test_bit(pagenr, rbio->dbitmap)) + continue; + if (stripe < rbio->nr_data) { page = page_in_rbio(rbio, stripe, pagenr, 1); if (!page) @@ -1304,6 +1321,11 @@ static noinline void finish_rmw(struct b for (pagenr = 0; pagenr < rbio->stripe_npages; pagenr++) { struct page *page; + + /* This vertical stripe has no data, skip it. */ + if (!test_bit(pagenr, rbio->dbitmap)) + continue; + if (stripe < rbio->nr_data) { page = page_in_rbio(rbio, stripe, pagenr, 1); if (!page) @@ -1729,6 +1751,33 @@ static void btrfs_raid_unplug(struct blk run_plug(plug); } +/* Add the original bio into rbio->bio_list, and update rbio::dbitmap. */ +static void rbio_add_bio(struct btrfs_raid_bio *rbio, struct bio *orig_bio) +{ + const struct btrfs_fs_info *fs_info = rbio->fs_info; + const u64 orig_logical = orig_bio->bi_iter.bi_sector << SECTOR_SHIFT; + const u64 full_stripe_start = rbio->bbio->raid_map[0]; + const u32 orig_len = orig_bio->bi_iter.bi_size; + const u32 sectorsize = fs_info->sectorsize; + u64 cur_logical; + + ASSERT(orig_logical >= full_stripe_start && + orig_logical + orig_len <= full_stripe_start + + rbio->nr_data * rbio->stripe_len); + + bio_list_add(&rbio->bio_list, orig_bio); + rbio->bio_list_bytes += orig_bio->bi_iter.bi_size; + + /* Update the dbitmap. */ + for (cur_logical = orig_logical; cur_logical < orig_logical + orig_len; + cur_logical += sectorsize) { + int bit = ((u32)(cur_logical - full_stripe_start) >> + PAGE_SHIFT) % rbio->stripe_npages; + + set_bit(bit, rbio->dbitmap); + } +} + /* * our main entry point for writes from the rest of the FS. */ @@ -1745,9 +1794,8 @@ int raid56_parity_write(struct btrfs_fs_ btrfs_put_bbio(bbio); return PTR_ERR(rbio); } - bio_list_add(&rbio->bio_list, bio); - rbio->bio_list_bytes = bio->bi_iter.bi_size; rbio->operation = BTRFS_RBIO_WRITE; + rbio_add_bio(rbio, bio); btrfs_bio_counter_inc_noblocked(fs_info); rbio->generic_bio_cnt = 1; @@ -2144,8 +2192,7 @@ int raid56_parity_recover(struct btrfs_f } rbio->operation = BTRFS_RBIO_READ_REBUILD; - bio_list_add(&rbio->bio_list, bio); - rbio->bio_list_bytes = bio->bi_iter.bi_size; + rbio_add_bio(rbio, bio); rbio->faila = find_logical_bio_stripe(rbio, bio); if (rbio->faila == -1) {