On Fri, Apr 8, 2016 at 12:18 PM, Austin S. Hemmelgarn <ahferroin7@xxxxxxxxx> wrote: > On 2016-04-08 14:05, Chris Murphy wrote: >> >> On Fri, Apr 8, 2016 at 5:29 AM, Austin S. Hemmelgarn >> <ahferroin7@xxxxxxxxx> wrote: >> >>> I entirely agree. If the fix doesn't require any kind of decision to be >>> made other than whether to fix it or not, it should be trivially fixable >>> with the tools. TBH though, this particular issue with devices >>> disappearing >>> and reappearing could be fixed easier in the block layer (at least, there >>> are things that need to be fixed WRT it in the block layer). >> >> >> Another feature needed for transient failures with large storage, is >> some kind of partial scrub, along the lines of md partial resync when >> there's a bitmap write intent log. >> > In this case, I would think the simplest way to do this would be to have > scrub check if generation matches and not further verify anything that does > (I think we might be able to prune anything below objects whose generation > matches, but I'm not 100% certain about how writes cascade up the trees). I > hadn't really thought about this before, but now that I do, it kind of > surprises me that we don't have something to do this. > And I need to better qualify this: this scrub (or balance) needs to be initiated automatically, perhaps have some reasonable delay after the block layer informs Btrfs the missing device as reappeared. Both the requirement of a full scrub as well as it being a manual scrub, are pretty big gotchas. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
