What about btfs check (no repair), without and then also with --mode=lowmem?
In theory I like the idea of a 24 hour rollback; but in normal usage Btrfs will eventually free up space containing stale and no longer necessary metadata. Like the chunk tree, it's always changing, so you get to a point, even with snapshots, that the old state of that tree is just - gone. A snapshot of an fs tree does not make the chunk tree frozen in time. To do what you want, maybe isn't a ton of work if it could be based on a variation of the existing btrfs seed device code. Call it a "super snapshot". I like the idea of triage, where bad parts of the file system can just be cut off, like triage. Compared to other filesystems, they'll say this is hardware sabotage and nothing can be done. Btrfs is a bit deceptive in that it sorta invites the idea we can use hardware that isn't proven, and the fs can survive. In any case, it's a big problem in my mind if no existing tools can fix a file system of this size. So before making anymore changes, make sure you have a btrfs-image somewhere, even if it's huge. The offline checker needs to be able to repair it, right now it's all we have for such a case. 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
