On 2019/7/14 下午11:40, Chris Murphy wrote: > On Sun, Jul 14, 2019 at 3:49 AM Qu Wenruo <quwenruo.bt...@gmx.com> wrote: >> >> I totally understand that the solution I'm going to provide sounds >> aweful, but I'd recommend to use a newer enough kernel but without that >> check, to copy all the data to another btrfs fs. >> >> It could be more safe than waiting for a btrfs check to repair it. > > Does the problem affect all trees? If so, then merely creating new > subvolumes, and then 'cp -a --relink oldsubvol newsubvol', and then > delete old subvolumes, won't fix it.
Not 100% sure yet, but from your dump, it's affecting INODE_ITEM and DIR_INDEX/DIR_ITEM. For other trees, only root tree and data reloc tree has INODE_ITEM. They may get affected but shouldn't be a problem. > > I wonder where the ideas are for online or even out of band fsck. > Offline fsck is too slow and does not scale, a known problem. And both > copying old file system to new file system; as well as restoring > backups to a new file system, is astronomically slower because data > must also be copied, not just metadata. Also a known problem. > > What about a variation on btrfs send/receive with --no-data option, to > read out all the old metadata and rewrite all new metadata to the same > file system, taking advantage of COW, but without having to copy out > the data? And then after all of that is done, delete the old file > subvolumes? It looks possible, but the use case also looks very limited. Just the case you're hitting, not a generic use case. So I'm afraid it won't be possible in short term. Thanks, Qu > > Or a variation on seed/sprout, without requiring additional devices. > The seed part "snapshots" the whole original file system (all trees), > and create two read-write file systems: current online mounted volume, > and in-progress offline repair volume. If the repair fails, it's > straightforward to clean up everything while retaining the changes - > at least it's not worse off. If the repair succeeds, then there'd need > to be some means of merging the two read-write file systems - that > could be complicated. But even if in the short term that merge > required an unmount, and perform the merge offline, that would be way > more tolerable than the way things are now. > >
signature.asc
Description: OpenPGP digital signature
