Thread (5 messages) 5 messages, 4 authors, 2021-02-19

Re: [PATCH] btrfs-progs: --init-extent-tree if extent tree is unreadable

From: David Sterba <hidden>
Date: 2021-02-19 12:46:00

On Wed, Aug 12, 2020 at 07:14:44PM +0200, David Sterba wrote:
On Wed, Aug 12, 2020 at 09:29:18AM +0800, Qu Wenruo wrote:
quoted
On 2020/7/28 上午10:12, Daniel Xu wrote:
quoted
This change can save the user an extra step of running `btrfs check
--init-extent-tree ...` if the user was already trying to repair the
filesystem.
This looks too aggressive to me.

Extent tree repair, not only --init-extent-tree, is not considered safe
overall.

In fact, we could hit cases with things like completely sane fs trees,
but corrupted extent and csum trees.

In that case, I'm not sure --init-extent-tree would solve or just worse
the situation.

Thus --init-extent-tree should only be triggered by users who know what
they are doing.
(In that case, I would call them developers other than users)
I have basically the same answer, just did not get to writing it.  I'll
have another look after the merge window is over.

This touches on the higher level topic what shoud check do, we can't
trade convenience for safety. The extra step to specify the option on
the command line can be actually the difference between repairing and
not repairing.
To answer that, favoring safety over convenience here, so the option
needs to be specified manually if needed.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help