From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 236BBC43441 for ; Mon, 26 Nov 2018 16:53:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DEA1D20855 for ; Mon, 26 Nov 2018 16:53:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="uxwEEsn/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DEA1D20855 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-btrfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726318AbeK0DsF (ORCPT ); Mon, 26 Nov 2018 22:48:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:55342 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726203AbeK0DsF (ORCPT ); Mon, 26 Nov 2018 22:48:05 -0500 Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5C9E320862 for ; Mon, 26 Nov 2018 16:53:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543251204; bh=eoqlXedZdgUdJuqnvZfQIQUaksTEeU7VRRB5U2aaGXg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=uxwEEsn/qLRFzstSVUzHK7zCs6eaKu7J9hOqgjKAIzZxw+nQXzvJYhvoFRk3fzR3A LPbF2U7TEw0uEBNglZGpD5BBzLIwVdxZu6jjvId8pdzsF+pb3QgMPZHM80GACyGpAN CBmRIgAEtwo7f14nJp9R1XwDY/53U+skhqBDAorM= Received: by mail-vk1-f172.google.com with SMTP id n126so4321841vke.12 for ; Mon, 26 Nov 2018 08:53:24 -0800 (PST) X-Gm-Message-State: AA+aEWanMRmtM0CEPWBjovKfAbllsRmYXVq2UYEMjlNBD5+ZiwcHSETy a7bKx/XTptn6aeNPU4eRbTZN9c4WdCrCdYMJysw= X-Google-Smtp-Source: AFSGD/W4dDPhcetIrtnGM+R09IsryJNv0I9Zi+6mxJk55wXwbQPjzTN9Pe8UUm13LMgZkOeXIO1X40xuwRuSHZA+BTI= X-Received: by 2002:a1f:10d7:: with SMTP id 84mr11229718vkq.88.1543251202985; Mon, 26 Nov 2018 08:53:22 -0800 (PST) MIME-Version: 1.0 References: <20181116110845.28561-1-fdmanana@kernel.org> In-Reply-To: <20181116110845.28561-1-fdmanana@kernel.org> From: Filipe Manana Date: Mon, 26 Nov 2018 16:53:11 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Btrfs: bring back key search optimization to btrfs_search_old_slot() To: linux-btrfs Cc: David Sterba Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Fri, Nov 16, 2018 at 11:09 AM wrote: > > From: Filipe Manana > > Commit d7396f07358a ("Btrfs: optimize key searches in btrfs_search_slot"), > dated from August 2013, introduced an optimization to search for keys in a > node/leaf to both btrfs_search_slot() and btrfs_search_old_slot(). For the > later, it ended up being reverted in commit d4b4087c43cc ("Btrfs: do a > full search everytime in btrfs_search_old_slot"), from September 2013, > because the content of extent buffers were often inconsistent during > replay. It turned out that the reason why they were often inconsistent was > because the extent buffer replay stopped being done atomically, and got > broken after commit c8cc63416537 ("Btrfs: stop using GFP_ATOMIC for the > tree mod log allocations"), introduced in July 2013. The extent buffer > replay issue was then found and fixed by commit 5de865eebb83 ("Btrfs: fix > tree mod logging"), dated from December 2013. > > So bring back the optimization to btrfs_search_old_slot() as skipping it > and its comment about disabling it confusing. After all, if unwinding > extent buffers resulted in some inconsistency, the normal searches (binary > searches) would also not always work. > > Signed-off-by: Filipe Manana David, please remove this change from the integration branch. It turns out after 3 weeks of stress tests it finally triggered an assertion failure (hard to hit) and it's indeed not reliable to use the search optimization because of how the mod log tree currently works. The idea was just to not make it different from btrfs_search_slot(). Use of the mod log tree is limited to some cases where occasional faster search wouldn't bring much benefits. Thanks. > --- > fs/btrfs/ctree.c | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c > index 089b46c4d97f..cf5487a79c96 100644 > --- a/fs/btrfs/ctree.c > +++ b/fs/btrfs/ctree.c > @@ -2966,7 +2966,7 @@ int btrfs_search_old_slot(struct btrfs_root *root, const struct btrfs_key *key, > int level; > int lowest_unlock = 1; > u8 lowest_level = 0; > - int prev_cmp = -1; > + int prev_cmp; > > lowest_level = p->lowest_level; > WARN_ON(p->nodes[0] != NULL); > @@ -2977,6 +2977,7 @@ int btrfs_search_old_slot(struct btrfs_root *root, const struct btrfs_key *key, > } > > again: > + prev_cmp = -1; > b = get_old_root(root, time_seq); > level = btrfs_header_level(b); > p->locks[level] = BTRFS_READ_LOCK; > @@ -2994,11 +2995,6 @@ int btrfs_search_old_slot(struct btrfs_root *root, const struct btrfs_key *key, > */ > btrfs_unlock_up_safe(p, level + 1); > > - /* > - * Since we can unwind ebs we want to do a real search every > - * time. > - */ > - prev_cmp = -1; > ret = key_search(b, key, level, &prev_cmp, &slot); > > if (level != 0) { > -- > 2.11.0 >