On Mon, Jul 2, 2018 at 8:42 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > > > On 2018年07月02日 22:05, Marc MERLIN wrote: >> On Mon, Jul 02, 2018 at 02:22:20PM +0800, Su Yue wrote: >>>> Ok, that's 29MB, so it doesn't fit on pastebin: >>>> http://marc.merlins.org/tmp/dshelf2_inspect.txt >>>> >>> Sorry Marc. After offline communication with Qu, both >>> of us think the filesystem is hard to repair. >>> The filesystem is too large to debug step by step. >>> Every time check and debug spent is too expensive. >>> And it already costs serveral days. >>> >>> Sadly, I am afarid that you have to recreate filesystem >>> and reback up your data. :( >>> >>> Sorry again and thanks for you reports and patient. >> >> I appreciate your help. Honestly I only wanted to help you find why the >> tools aren't working. Fixing filesystems by hand (and remotely via Email >> on top of that), is way too time consuming like you said. >> >> Is the btrfs design flawed in a way that repair tools just cannot repair >> on their own? > > For short and for your case, yes, you can consider repair tool just a > garbage and don't use them at any production system.
So the idea behind journaled file systems is that journal replay enabled mount time "repair" that's faster than an fsck. Already Btrfs use cases with big, but not huge, file systems makes btrfs check a problem. Either running out of memory or it takes too long. So already it isn't scaling as well as ext4 or XFS in this regard. So what's the future hold? It seems like the goal is that the problems must be avoided in the first place rather than to repair them after the fact. Are the problem's Marc is running into understood well enough that there can eventually be a fix, maybe even an on-disk format change, that prevents such problems from happening in the first place? Or does it make sense for him to be running with btrfs debug or some subset of btrfs integrity checking mask to try to catch the problems in the act of them happening? -- Chris Murphy -- 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
