►
From YouTube: Healing With ZFS Receive by Alek Pinchuk
Description
From the 2019 OpenZFS Developer Summit
slides: https://drive.google.com/open?id=1Ysc_3bJWmsJCETFNTRCzyvpseDpzjjf2
A
B
C
B
B
But
the
good
news
is
that
most
admins
and
companies
have
remote
copies
of
data
now
somewhere,
there's
a
backup
of
what
you
have
in
production,
and
wouldn't
it
be
nice
to
use
that
to
heal
data.
If
you
have
corrupted
it
right.
So
that's
what
we
were
talking
about
at
some
point
and
Tom
suggested
we
do
just
that
and
I
am
planted
it
while
I
was
still
working
in
debt.
B
So
yeah,
you
can
go
right
now
to
this
link
and
see
the
code
and
it
has
a
bunch
of
references
to
corrective
or
healing
receive,
and
that's
just
shorter,
but
the
receive
age
was
taken
by
somebody,
so
this
became
correct
to
receive
receive
see.
So
the
second
line
right
here
is
how
you
an
example
of
indicating
this
healing
receiver,
so
you
give
it
received,
see
then
the
snapshot
and
the
send
file
that
you're
healing
from
so
how
does
this
work?
B
B
So
if
this
that
a
goodies
match,
we
can
move
on
to
looking
at
the
records
inside
of
this
end
file.
So
we
can
look
inside
of
each
write
and
spill
record
pick
out
the
objects
that
object
ID,
offset
the
data
and
then
figure
out
what
the
corresponding
block
is
on
disk
for
those
for
the
records
that
are
described
with
this
object
set
and
object
ID.
B
So
once
we
get
the
block
pointer
through
this,
we
can
read
the
block
from
disk,
and
if
this
read
comes
back
with
a
checksum
error,
we
know
that
that
block
is
corrupted
right,
and
in
this
case
this
is
where
the
healing
receive
comes
into
play.
We
we
can
use
the
data
or
we,
this
patch
just
uses
the
data
from
the
centrum
to
basically
reconstruct
the
data
on
disk,
and
it
can
do
things
like
recompress.
B
If
the
sen
stream
is
not
compressed,
for
example,
but
the
data
on
disk
is
compressed,
it
can
recompress
the
data
the
same
way
so
that
you
can
match
it
so
that
you
can
use
it
for
healing,
and
one
of
the
key
points
from
here
is:
is
that
it
never
does
anything
so
correct?
The
receive
won't
do
anything
unless
the
reconstructed
block
matches
what
the
checksum
for
the
reconstructed
block
matches.
What's
on
disk,
so.
C
B
B
B
C
C
B
C
B
B
C
B
Through
the
whole
snapshot,
the
whole
sent
file
yeah,
which
is
slower
obviously
than
having
a
minimal
purpose-built
corruption,
I'm
healing
sound
file.
So
as
far
as
testing
I've
implemented
a
pretty
good
test
for
the
right
side
of
it,
but
this
bill
block
testing
has
only
been
manual
so
far
and
the
reason
is
I'm
not
I.
Think
I
figured
out
how
to
do
the
rest
of
it.
How
to
automate
the
rest
of
it.
I've
done
the
testing
manually,
but
yeah
right
now,
what's
what's
being
tested
in
the
PR
is
full.
B
Then
recompression
and
then
I
also
have
a
test
for
the
part
that
I'm
still
working
on,
which
is
the
re
encrypting
the
data
but
yeah
this
bill
block
is
harder
to
do
because
so
somebody
added
a
really
nice
function
to
ZFS
test
suite,
which
is
just
able
to
corrupt
files
and
I.
Don't
think
that
actually
works
for
its
pillbox
yet,
but
yeah
I
think
I
know
how
to
work
around
that
so
that'll
be
another
part.
I
should
be
getting
to
relatively
soon
right.
Now,
it's
the
demo
time.
B
C
A
B
B
C
B
B
I'm
not
sure
I
haven't
tested
that,
but
it
hooks
into
the
existing
you
know
receive
right
record,
receive
spill
records
so
as
long
as
that
laid
out
the
right
way,
I
think
it
should
but
yeah,
there's,
probably
other
corner
cases
haven't
considered.
So
if
anybody
knows
some
edge
cases
with
send
received
that
I
should
be
testing.
Let
me
know.
B
C
B
Is
I
was
debating
and
if
this
is
a
good
idea
and
not
to
have
this
restriction,
but
I
figured
most
of
the
time,
we
will
have
replicas
that
are
available
that
so
you
know
you
can
have
several
snapshots
and
as
long
as
you
have
them
on
both
sides,
you
can
heal
the
same
blocks
with
the
same
snapshots
or
the
same
block
with
a
bunch
of
different
snapshots.
So
I
figured
that
probably
would
be
okay,
but
it
is
our
betrayer
like
I,
was
saying.