On 2019/10/16 下午4:12, Roman Mamedov wrote: > On Wed, 16 Oct 2019 15:45:54 +0800 > Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > >> dirty fixes (a special branch for the user >> to do, never intended to upstream). > > Still it would be nice to get a btrfs check mode which would include trying > destructive actions, as in accepting the loss of some part of user data > (outright delete corrupt blocks, etc), just to restore the filesystem itself to > a fully correct and mountable state. It's already there. The problem is, that mode only works for fs tree, and it can only handle cases like full corrupted (not transid, but the child node/leaf can't be read out completely). > > Sometimes there are cases when it is inconvenient to recreate the entire FS > (remember seeing 40TB mentioned recently), just to fix a few "parent transid > failed", not even many transactions apart. That transid problem is the biggest and the most complext problem. Transid problem can lead to futher corruption, like a tree block is completely incorrect in the context of parent tree. E.g. a csum tree block points to a fs tree block. So we can't easily treat transid by easily ignore them. But your idea is pretty god, maybe we should tread transid error as bad csum, and completely ignore the child, do the regular corrupted leaf/node repair. Thanks, Qu > And the data itself is often backed > up, so restoring only the missing part from the backup would be much easier. >
