At 01/23/2017 07:15 PM, Sebastian Gottschall wrote:
Hello again
by the way. the init-extent-tree is still running (now almost 7 days).
is there any chance to find out how long it will take at the end?
Sebastian
I think it may encounters a dead loop.
If its output doesn't loop(from a large scale), then you could try wait.
But at the point trying --init-extent-tree, your chance to recover your
fs is quite low then.
Sorry for that.
Thanks,
Qu
Am 20.01.2017 um 02:08 schrieb Qu Wenruo:
At 01/19/2017 06:06 PM, Sebastian Gottschall wrote:
Hello
I have a question. after a power outage my system was turning into a
unrecoverable state using btrfs (kernel 4.9)
since im running --init-extent-tree now for 3 days i'm asking how long
this process normally takes and why it outputs millions of lines like
--init-extent-tree will trash *ALL* current extent tree, and *REBUILD*
them from fs-tree.
This can takes a long time depending on the size of the fs, and how
many shared extents there are (snapshots and reflinks all counts).
Such a huge operation should only be used if you're sure only extent
tree is corrupted, and other tree are all OK.
Or you'll just totally screw your fs further, especially when
interrupted.
Backref 1562890240 root 262 owner 483059214 offset 0 num_refs 0 not
found in extent tree
Incorrect local backref count on 1562890240 root 262 owner 483059214
offset 0 found 1 wanted 0 back 0x23b0211d0
backpointer mismatch on [1562890240 4096]
This is common, since --init-extent-tree trash all extent tree, so
every tree-block/data extent will trigger such output
adding new data backref on 1562890240 root 262 owner 483059214 offset 0
found 1
Repaired extent references for 1562890240
But as you see, it repaired the extent tree by adding back
EXTENT_ITEM/METADATA_ITEM into extent tree, so far it works.
If you see such output with all the same bytenr, then things goes
really wrong and maybe a dead loop.
Personally speaking, normal problem like failed to mount should not
need --init-extent-tree.
Especially, extent-tree corruption normally is not really related to
mount failure, but sudden remount to RO and kernel wanring.
Thanks,
Qu
please avoid typical answers like "potential dangerous operation" since
all repair options are declared as potenial dangerous.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
