----- Original Message -----
From: "Rich" <[email protected]>
So, the commit you referenced is the commit that introduced the
behavior of "in these error cases, we can't figure out what's in use
reliably, so 'leak the space', log that we leaked it, and that way we
don't corrupt things at the cost of space".
So I would posit that the problem may be one of a leaking/corruption
condition being triggered that simply wasn't noted prior to said
commit, rather than being a logical flaw in that commit?
I need to investigate more to confirm that.
You've helpfully included all the resources needed for someone to
replicate this on their own, which should help a lot, presuming that
people don't immediately find some counter-examples to your train of
logic (which doesn't seem flawed to my eyes, at the moment).
Have you actually tried this on any non-FBSD platforms yet to see if
this is as reliably replicable there yet?
Unfortunately I only have access to FreeBSD installs here, my old illumos
box is very out of date and it took me days to get working last time ;-)
I'm honestly kind of terrified by the prospect of a nice poisonous
dataset that can cause your pool to leak space until it's gone, so
I'll probably test this on some testbed as soon as I set one up that
has nothing else being tested on it I'd mind losing...
Indeed!
FreeBSD is currently in the final stages of 10.1 release process so
I've already informed the Release Engineering team of this issue as it
appears to result in unrecoverable pool. For the original reporterit
resulted in a unbootable machine, as it had leaked that much the pool
didnt have enough space to perform the import on boot.
For reference in my test it leaked over 2GB in under 12hours.
Regards
Steve
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
