On 1/17/20 2:29 AM, Qu Wenruo wrote:
Before this patchset, the only way to repair invalid extent item
generation is to use --init-extent-tree, which is really a bad idea.
To rebuild the whole extent tree just for one corrupted extent item?
I must be insane at that time.
This patch introduces the proper extent item generation repair
functionality for both mode, and alter existing test case to also test
repair.
Qu Wenruo (3):
btrfs-progs: check/lowmem: Repair invalid extent item generation
btrfs-progs: check/original: Repair extent item generation
btrfs-progs: tests/fsck-044: Enable repair test for invalid extent
item generation
check/main.c | 66 +++++++++++++++++
check/mode-lowmem.c | 74 +++++++++++++++++++
.../.lowmem_repairable | 0
.../test.sh | 19 -----
4 files changed, 140 insertions(+), 19 deletions(-)
create mode 100644 tests/fsck-tests/044-invalid-extent-item-generation/.lowmem_repairable
delete mode 100755 tests/fsck-tests/044-invalid-extent-item-generation/test.sh
If we have a generation > super generation that means that block is from the
future and we shouldn't trust anything in it right? I haven't touched this code
in a while, but that just meant we threw it away and any extent references that
were in that block were just re-created. Is that not what's happening now?
This seems like a bad way to go about fixing this particular problem. Thanks,
Josef
