Re: [PATCH v1.1 00/14] btrfs-progs: check: Use fs/subvol trees to fix extent tree, not vice versa

From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org, David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH v1.1 00/14] btrfs-progs: check: Use fs/subvol trees to fix extent tree, not vice versa
Date: Thu, 28 Mar 2019 13:51:18 +0800	[thread overview]
Message-ID: <5db416d0-ada1-3ea6-bac1-88eaedea61c1@gmx.com> (raw)
In-Reply-To: <20190227060552.3841-1-wqu@suse.com>

[-- Attachment #1.1: Type: text/plain, Size: 3622 bytes --]

Gentle ping?

Any comment on this?

Thanks,
Qu

On 2019/2/27 下午2:05, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/btrfs-progs/tree/file_extents_fixes
> 
> This is based on v4.20.2 tag.
> 
> Originally for fsck-tests/001-bad-file-extent-bytenr we're going to fix
> it by resetting the corrupted file extent, using the disk bytenr from
> data backref.
> 
> However in real world, extent tree is the most fragile one while fs tree
> is more reliable.
> This means fixing using extent tree can sometimes be more dangerous, and
> causing extra corruption from repair.
> 
> Further more, that test case is a big blockage for any later
> modification on file extent repair code.
> 
> So the goal of this patchset is to change the repair behavior from
> rebuilding file extents using data backref, to dropping invalid file
> extents and modify extent tree.
> 
> Despite above change, we have some small bug fixes for:
> - False alert for file extents gap
> - Bad data backref -> file extent search in repair mode
> 
> The patchset is mostly from Fujitsu guys (Lu, Su Yue, Su Yanjun).
> My work here is:
> - Solve rebase conflicts
>   Mostly with DIR_ITEM hash mismatch patchset
> 
> - Commit message/comment update
>   Make them a little more reader friendly
> 
> - Reorder the patchset
>   Make small fixes first.
> 
> Changelog:
> v1.1:
> - Rebase to v4.20.2
> - Run self tests for misc/mkfs/fsck group.
>   The only problem is from misc/035, due to we have reverted the fix.
>   It's not a regression so the patchset should still be good.
> 
> Lu Fengqi (2):
>   btrfs-progs: lowmem: fix false alert about the existence of gaps in
>     the check_file_extent
>   btrfs-progs: tests: add case for inode lose one file extent
> 
> Qu Wenruo (1):
>   btrfs-progs: Update backup roots when writing super blocks
> 
> Su Yanjun (4):
>   btrfs-progs: Revert "btrfs-progs: Add repair and report function for
>     orphan file extent."
>   btrfs-progs: Revert "btrfs-progs: Record orphan data extent ref to
>     corresponding root."
>   btrfs-progs: check: fix wrong @offset used in find_possible_backrefs()
>   btrfs-progs: check: Delete file extent item with unaligned disk bytenr
> 
> Su Yue (7):
>   btrfs-progs: lowmem: add argument path to punch_extent_hole()
>   btrfs-progs: lowmem: move nbytes check before isize check
>   btrfs-progs: lowmem: fix false alert if extent item has been repaired
>   btrfs-progs: lowmem: check unaligned disk_bytenr for extent_data
>   btrfs-progs: lowmem: rename delete_extent_tree_item() to delete_item()
>   btrfs-progs: lowmem: delete unaligned bytes extent data under repair
>   btrfs-progs: fsck-test: enable lowmem repair for case 001
> 
>  check/main.c                                  | 584 +++++++++++-------
>  check/mode-lowmem.c                           | 293 +++++----
>  check/mode-original.h                         |  30 +-
>  ctree.h                                       |  10 +-
>  disk-io.c                                     |  80 ++-
>  .../.lowmem_repairable                        |   0
>  .../.lowmem_repairable                        |   0
>  .../default_case.img                          | Bin 0 -> 3072 bytes
>  8 files changed, 621 insertions(+), 376 deletions(-)
>  create mode 100644 tests/fsck-tests/001-bad-file-extent-bytenr/.lowmem_repairable
>  create mode 100644 tests/fsck-tests/038-missing-one-file-extent/.lowmem_repairable
>  create mode 100644 tests/fsck-tests/038-missing-one-file-extent/default_case.img
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]