Anton B. Rang wrote:
Also note that the UB is written to every vdev (4 per disk) so the
chances of all UBs being corrupted is rather low.
The chances that they're corrupted by the storage system, yes.
However, they are all sourced from the same in-memory buffer, so
an undetected in-memory err
> > Also note that the UB is written to every vdev (4 per disk) so the
> > chances of all UBs being corrupted is rather low.
>
> The chances that they're corrupted by the storage system, yes.
>
> However, they are all sourced from the same in-memory buffer, so an
> undetected in-memory error (e.
> Also note that the UB is written to every vdev (4 per disk) so the
> chances of all UBs being corrupted is rather low.
The chances that they're corrupted by the storage system, yes.
However, they are all sourced from the same in-memory buffer, so an undetected
in-memory error (e.g. kernel bug
> [...] there is no possibility of referencing an overwritten
> block unless you have to back off more than two uberblocks. At this
> point, blocks that have been overwritten will show up as corrupted (bad
> checksums).
Hmmm. Is there some way we can warn the user to scrub their pool because we
