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
