Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp118793ybi; Wed, 29 May 2019 17:54:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqwZHZEkob9Y5J4XhxTwqunkcKdTi759Ua5+leEM01Is8n1F6cqm0NLZ/ACvEmBV5RG0MEw3 X-Received: by 2002:a62:e00e:: with SMTP id f14mr604940pfh.257.1559177685427; Wed, 29 May 2019 17:54:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559177685; cv=none; d=google.com; s=arc-20160816; b=pdNgFo7YZEAke52eG7P73f2+u/wG8ZsqdfvmVQKOOBQUc5fl2rmFL9WcTFnIDRQJ1d rfiYqlkkNHu0QJ6AlWugXz0Aa/fTV3bruWtl4wSpAvgk66G4jFX+fA3Tthpd9PVRzxsh 1ZKDFoy9cAlEAWqmsFcyI6sSuqpw7gGcb8ihf2spg2Gjw2naUHEJWnCEHYVEJTWEilDD WwOKpSNNYKyPCOek7guR1jAK257DDAhPrE2z0FJXnKuosgArR7MA5ECdZjxcssFvgbhl VTxA9fgZ1dEpJZYhgDgKf3RgRBxsVqc/+TNizEMNvty5kzCc1y1nXoYZNhUwSv54aiNb /yBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:from:subject:references :mime-version:message-id:in-reply-to:date:dkim-signature; bh=1zLLzunRacIsvbkfTaWpC4CoBmiOmCh3qurXkU7Ik8U=; b=dZQPBXSDTq2/+2vCaFbC7EmbmXIIqadLv4PDKqbLGOXs9U/zwzyQO8oV7ijI4UlSNM 35LogAiL1kQWuDxQPhnXuh+wxBfFgdp8r4WxibOuyOj/LuYHBR98SENJGMHvYmCBmPAm cx4TZpmCKbd1Kk+zFo1+zIOSq9okhIivouJ8Ttun5KJALH7OX4Svh0fVIhRyThBUNq8t lFWnUASyRHGOSYQCtxlx3ueQDGxGENMgp6EMJd12l/NgoXvduDum3u/058EhPoUUGy/+ LXqmg1pVKMJgOUpowZWIKxrbeUHHHbqp9wakeUXFo2flAZlrgWJ2eTr//eJ6nbRmtR4A lMEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=h8FHABKx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w4si1341788plp.223.2019.05.29.17.54.29; Wed, 29 May 2019 17:54:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=h8FHABKx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727216AbfE3AxV (ORCPT + 99 others); Wed, 29 May 2019 20:53:21 -0400 Received: from mail-pl1-f202.google.com ([209.85.214.202]:52782 "EHLO mail-pl1-f202.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727194AbfE3AxU (ORCPT ); Wed, 29 May 2019 20:53:20 -0400 Received: by mail-pl1-f202.google.com with SMTP id q2so2751603plr.19 for ; Wed, 29 May 2019 17:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=1zLLzunRacIsvbkfTaWpC4CoBmiOmCh3qurXkU7Ik8U=; b=h8FHABKxdlBN53cFTYJ5d0UiBL7PihQINuldUv4FTl0bNIxkuNBt/0Vhf2uJoL5oHc ntnxQeBd3+C8qEPYr5NVptJ+q35h8Vb6fgT/+ZS105INBTY18oRGfX0xwxo1L6VPNRA5 c22OcQrAt10dKzRjCahiaTgdDbZ/vBceEd0fjRMjFH/6+q0u9FQKKJf/x+fsZdfIY04A Vc4TLPxz0LbwxUj10798jCsJzwt35n5zYTHpIofjFuIp+AqXXRE63vKbMXk1C/H9oUB6 yHBPeUJEjTFKYiZzaX0gOwoHu4F0VQMZ+O+jfseDir1gYMx+VP4rwUkz9NYSSctfnSkb q/KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=1zLLzunRacIsvbkfTaWpC4CoBmiOmCh3qurXkU7Ik8U=; b=FFt+2RyuoSUpGg+fkdB9oDXIt+xursWTV0yo7AIW2fl5kKoeZCUdBBGhw4sIStzf8T vOIRBRvylIaJpisPyA8EGdV28daAKYAgH3J+1x7Xds/LbSGrw4DFtKYEx21TwWo0v+3p /OELvZHWsnrP5raMOzowSebAo7JYZiwtPKNwKgTkhCruwDk81vg5XEeXkClo36Xy6UgF l7zFWNTme2x7SmXq0aI7in7JUPgoM62k/hsmvhfeKeKzdHb+4TeJTiixleoJquoOYj/I qSVWWc7K/YvfyS6/NCgQHbluaBv6x9zpll8atCcCIzOa1lecXyiTsmuxNKaZN1aDMgyM cRkQ== X-Gm-Message-State: APjAAAVtMP30ke2oPsocSO8kn4NIL8UmWysGNnTEEvm4okOnY2e5WzyJ qRPjFBViG7qNhPG8ma4Xtt5idJB5YXg= X-Received: by 2002:a63:1622:: with SMTP id w34mr958542pgl.45.1559177599505; Wed, 29 May 2019 17:53:19 -0700 (PDT) Date: Wed, 29 May 2019 17:49:03 -0700 In-Reply-To: <20190530004906.261170-1-drosen@google.com> Message-Id: <20190530004906.261170-2-drosen@google.com> Mime-Version: 1.0 References: <20190530004906.261170-1-drosen@google.com> X-Mailer: git-send-email 2.22.0.rc1.257.g3120a18244-goog Subject: [PATCH v3 1/4] f2fs: Lower threshold for disable_cp_again From: Daniel Rosenberg To: Jaegeuk Kim , Chao Yu , Jonathan Corbet , linux-f2fs-devel@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, kernel-team@android.com, Daniel Rosenberg Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The existing threshold for allowable holes at checkpoint=disable time is too high. The OVP space contains reserved segments, which are always in the form of free segments. These must be subtracted from the OVP value. The current threshold is meant to be the maximum value of holes of a single type we can have and still guarantee that we can fill the disk without failing to find space for a block of a given type. If the disk is full, ignoring current reserved, which only helps us, the amount of unused blocks is equal to the OVP area. Of that, there are reserved segments, which must be free segments, and the rest of the ovp area, which can come from either free segments or holes. The maximum possible amount of holes is OVP-reserved. Now, consider the disk when mounting with checkpoint=disable. We must be able to fill all available free space with either data or node blocks. When we start with checkpoint=disable, holes are locked to their current type. Say we have H of one type of hole, and H+X of the other. We can fill H of that space with arbitrary typed blocks via SSR. For the remaining H+X blocks, we may not have any of a given block type left at all. For instance, if we were to fill the disk entirely with blocks of the type with fewer holes, the H+X blocks of the opposite type would not be used. If H+X > OVP-reserved, there would be more holes than could possibly exist, and we would have failed to find a suitable block earlier on, leading to a crash in update_sit_entry. If H+X <= OVP-reserved, then the holes end up effectively masked by the OVP region in this case. Signed-off-by: Daniel Rosenberg --- fs/f2fs/segment.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 1a83115284b93..ec59cbd0e661d 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -876,7 +876,9 @@ void f2fs_dirty_to_prefree(struct f2fs_sb_info *sbi) int f2fs_disable_cp_again(struct f2fs_sb_info *sbi) { struct dirty_seglist_info *dirty_i = DIRTY_I(sbi); - block_t ovp = overprovision_segments(sbi) << sbi->log_blocks_per_seg; + int ovp_hole_segs = + (overprovision_segments(sbi) - reserved_segments(sbi)); + block_t ovp_holes = ovp_hole_segs << sbi->log_blocks_per_seg; block_t holes[2] = {0, 0}; /* DATA and NODE */ struct seg_entry *se; unsigned int segno; @@ -891,10 +893,10 @@ int f2fs_disable_cp_again(struct f2fs_sb_info *sbi) } mutex_unlock(&dirty_i->seglist_lock); - if (holes[DATA] > ovp || holes[NODE] > ovp) + if (holes[DATA] > ovp_holes || holes[NODE] > ovp_holes) return -EAGAIN; if (is_sbi_flag_set(sbi, SBI_CP_DISABLED_QUICK) && - dirty_segments(sbi) > overprovision_segments(sbi)) + dirty_segments(sbi) > ovp_hole_segs) return -EAGAIN; return 0; } -- 2.22.0.rc1.257.g3120a18244-goog