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. 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? 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. -- Chris Murphy
