On Thu, Jul 13, 2017 at 08:40:12AM +0200, Adam Borowski wrote: > Here's a set of test cases, two of them in some cases seem to scribble upon > the wrong device: > > * deg-mid-missing > * deg-last-replaced (not on the innocent "re") > * but never deg-last-missing > > When all goes ok, there are no errors other than wrong generation on the > re-added disk (expected). When it goes bad, there's a lot of corruption. > In all cases, though, the "Device missing:" field is wrong.
I did not explore this adequately yet, in a good part because of ENOSPC triggering a lot of time for an unrelated reason that Omar just fixed (thanks!). So, here's what I know so far: * copying in, say, 2.2GB /usr/share is a lot more likely to trigger than dd-ing 2.2GB of /dev/null * no "real" degrading is needed: in the original scripts, the missing device is empty so all blocks are doubled anyway. It's not about degraded chunks but because of a bogus device. * bogus output of "btrfs f u" is a sure predictor that, with enough tries, you'll get corruption -- if it shows something when it should say "missing", shit is likely to happen Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄⠀⠀⠀⠀ A master species delegates. -- 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
