LKML Archive on
help / color / mirror / Atom feed
From: Chao Yu <>
To: Daniel Rosenberg <>,
	Jaegeuk Kim <>,
	Jonathan Corbet <>,
Cc: <>, <>,
	<>, <>
Subject: Re: [PATCH v3 1/4] f2fs: Lower threshold for disable_cp_again
Date: Mon, 3 Jun 2019 18:33:30 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2019/5/30 8:49, Daniel Rosenberg wrote:
> 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 <>

Reviewed-by: Chao Yu <>


  reply	other threads:[~2019-06-03 10:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30  0:49 [PATCH v3 0/4] F2FS Checkpointing without GC, related fixes Daniel Rosenberg
2019-05-30  0:49 ` [PATCH v3 1/4] f2fs: Lower threshold for disable_cp_again Daniel Rosenberg
2019-06-03 10:33   ` Chao Yu [this message]
2019-05-30  0:49 ` [PATCH v3 2/4] f2fs: Fix root reserved on remount Daniel Rosenberg
2019-06-03 10:34   ` Chao Yu
2019-05-30  0:49 ` [PATCH v3 3/4] f2fs: Fix accounting for unusable blocks Daniel Rosenberg
2019-06-03 10:39   ` Chao Yu
2019-06-03 20:26     ` Jaegeuk Kim
2019-06-04  1:46       ` Chao Yu
2019-05-30  0:49 ` [PATCH v3 4/4] f2fs: Add option to limit required GC for checkpoint=disable Daniel Rosenberg
2019-06-03 15:15   ` [f2fs-dev] " Chao Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v3 1/4] f2fs: Lower threshold for disable_cp_again' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).