Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Su Yue <l@damenly.su>
To: linux-btrfs@vger.kernel.org
Cc: l@damenly.su, nborisov@suse.com, boris@bur.io, dsterba@suse.cz
Subject: [PATCH RFC] btrfs-progs: check: continue to check space cache if sb cache_generation is 0
Date: Mon, 15 Feb 2021 17:20:11 +0800	[thread overview]
Message-ID: <20210215092011.6079-1-l@damenly.su> (raw)

User reported that test fsck-tests/037-freespacetree-repair fails:
 # TEST=037\* ./fsck-tests.sh
    [TEST/fsck]   037-freespacetree-repair
btrfs check should have detected corruption
test failed for case 037-freespacetree-repair

The test tries to corrupt FST, call btrfs check readonly then repair FST
using btrfs check. Above case failed at the second readonly check steup.
Test log said "cache and super generation don't match, space cache will
be invalidated" which is printed by validate_free_space_cache().
If cache_generation of the superblock is not -1ULL,
validate_free_space_cache() requires that cache_generation must equal
to the superblock's generation. Otherwise, it skips the check of space
cache(v1, v2) like the above case where the sb cache_generation is 0.

Since kernel commit 948462294577 ("btrfs: keep sb cache_generation
consistent with space_cache"), sb cache_generation will be set to be 0
once space cache v1 is disabled(nospace_cache/space_cache=v2).

Fix it by adding the condition if sb cache_generation is 0 in
validate_free_space_cache() as it's valid now since the kernel commit
mentioned above.

Link: https://github.com/kdave/btrfs-progs/issues/338
Signed-off-by: Su Yue <l@damenly.su>

---
Hi, while reading free space cache v1 related code, I am (still)
confused about the value meanings of cache_generation in sb.

For outdated space cache v1, cache_gen < sb gen.
For valid space cache v1, cache_gen == sb gen.
AS for values 0 and (u64)-1, many places use (u64)-1 to represent
cleared v1 caches. The only three places setting cache_gen to 0 are
1)  above kernel commit 948462294577.
2)  kernel btrfs_parse_options() while mounting zoned device.
3)  progs image/main.c:1147 while restoring image.

I'm wondering whether loosing check condition in this patch is correct
or not. So make it RFC. Thanks.
---
 check/main.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/check/main.c b/check/main.c
index c7c5408bea19..a652e445de90 100644
--- a/check/main.c
+++ b/check/main.c
@@ -9951,7 +9951,12 @@ static int validate_free_space_cache(struct btrfs_root *root)
 {
 	int ret;
 
+	/*
+	 * If cache generation is between 0 and -1ULL, sb generation must equal to
+	 *   sb cache generation or the v1 space caches are outdated.
+	 */
 	if (btrfs_super_cache_generation(gfs_info->super_copy) != -1ULL &&
+	    btrfs_super_cache_generation(gfs_info->super_copy) != 0 &&
 	    btrfs_super_generation(gfs_info->super_copy) !=
 	    btrfs_super_cache_generation(gfs_info->super_copy)) {
 		printf(
-- 
2.30.0


             reply	other threads:[~2021-02-15  9:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15  9:20 Su Yue [this message]
2021-02-17 22:18 ` [PATCH RFC] btrfs-progs: check: continue to check space cache if sb cache_generation is 0 Boris Burkov
2021-02-18  0:55   ` Su Yue

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20210215092011.6079-1-l@damenly.su \
    --to=l@damenly.su \
    --cc=boris@bur.io \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox