On 11/7/2018 2:38 PM, Qu Wenruo wrote:
On 2018/11/7 下午2:21, Su Yanjun <suyj.f...@cn.fujitsu.com> wrote:
On 10/24/2018 8:45 AM, Qu Wenruo wrote:
On 2018/10/23 下午5:41, Su Yue wrote:
From: Su Yanjun <suyj.f...@cn.fujitsu.com>
In original mode, if some file extent item has unaligned extent backref,
fixup_extent_refs can't repair it. This patch will check extent
alignment
then delete file extent with unaligned extent backref.
This looks a little strange to me.
You mean, an unaligned FILE EXTENT has an unaligned EXTENT_ITEM?
Then why not just delete the EXTENT_ITEM directly? No need to go back
checking if it has a corresponding EXTENT_DATA since unaligned one is
definitely corrupted.
For corrupted EXTENT_DATA, it should get deleted when we check fs tree.
This would save you a lot of codes.
Thanks,
Qu
The situation is that the file extent has wrong extent backref, actually
it doesn't exist.
Did you mean extent EXTENT_ITEM key's objectid is unaligned?
Would you please give an example on this case? Like:
(<ino> EXTENT_DATA <offset>
disk bytenr <XXXX> disk len <YYYY>
And its backref like:
(<XXXX> EXTENT_ITEM <YYYY>)
And then mark where the number is incorrect.
Thanks,
Qu
As in /btrfs-progs/tests/fsck-tests/001-bad-file-extent-bytenr case:
item 7 key (257 EXTENT_DATA 0) itemoff 3453 itemsize 53
generation 6 type 1 (regular)
extent data disk byte 755944791 nr 1048576
^^^^^^^^^
extent data offset 0 nr 1048576 ram 1048576
extent compression 0 (none)
Thanks,
Su
Thanks,
Su
