►
From YouTube: OpenZFS Developer Summit Part 4
Description
John W Kennedy on ZFS Test Coverage
E
A
Yeah,
because
right
now,
the
actual
interface
like
every
time
we
make
a
minor
change,
it's
like
add
a
new
flag
or
do
this
or
do
that
and
then
you
like,
because
every
time
what
they
were
saying
before
is
every
time
you
add
a
new
feature
you
have
to
plug
it
all
the
way
up
through
the
stack
and
add
new
iocals
and
everything.
So
this
would
be
one
app
that
you
send
down
two
eye
options.
One.
A
H
John
is
going
to
talk
to
us
about
test
coverage,
I'm
john
kennedy.
I
work
at
delfix
before
being
at
delfix.
I
was
in
sun
and
I
worked
in
rpe
doing
support
for
zfs
and
eventually
qa
and
that's
my
email
address
down
at
the
bottom
there.
So
if
you
find
like
I
do
often
once
the
presentation
is
over,
you
have
questions
that
you
wanted
to
ask
at
the
time.
Please
feel
free
to
drop
me
a
mail
and
let
me
know.
H
So
basically,
what
I
want
to
do
today
is
go
through
a
history
of
zfs
testing,
as
I've
known
it
and
also
find
out
what
the
state
of
the
world
is
in
terms
of
what
the
other
distributions
are
doing.
I
know
a
little
bit
about
what's
going
on,
but
I'm
sure
I
have
some
gaps
in
misconceptions
and
hopefully
we
can
fill
it
up
and
so,
even
from
a
delphic
specific
point
of
view,
there's
still
work
to
be
done
on
the
zfs
testing.
H
Stf
is
the
solaris
test
framework.
It's
used
for
a
lot
of
different
tests
in
the
solaris
test,
collection,
lots
of
file
systems,
network
drivers,
things
like
that
sun
opened
it
in
late
2009
and
then
after
the
oracle,
takeover
and
sort
of
the
closure.
In
that
regard,
it
kind
of
stagnated.
It
fell
through
the
cracks
a
little
bit.
H
We
picked
it
up
in
delfix
and
got
it
running
because
there
had
been
such
a
long
period
of
divergence
between
what
was
actually
happening
in
the
community
and
the
test
which
really
hadn't
progressed
at
all.
It
took
a
lot
of
work
to
get
the
test
failures
running
I'm
sure
you
guys
probably
had
some
more
more
was
the
bsd
guys
right
done
that
yeah.
H
They've
probably
done
some
more
work,
so
we
fixed
it
up
and
we
got
it
posted
on
github.
It's
still
there
now,
but
we
found
that
stf
had
some
difficulties
that
were
incompatible
with
some
of
the
things
we
wanted
for
our
test.
Suite.
For
example,
we
wanted
it
to
live
with
the
source
and
because
of
some
of
the
usability
issues
with
stf
and
because
of
kind
of
its
peculiar
ways
of
building.
We
decided
to
write
another
test
test
framework
from
scratch,
and
so
that's
how
we
got
the
test
runner.
H
H
H
H
Oh
yeah
there's
some
areas
that
are
like
we
have
coverage
for
them,
but
the
coverage
could
be
more
complete
in
terms
of
what
what
those
tests
apply
to,
even
when
they
were
written
and
also
the
the
features
that
they
replied
to
have
sort
of
grown
in
the
interim
so
send
receive,
is
probably
the
best
example
of
that.
There's
a
good
deal
of
work
that
needs
to
be
done
to
improve
those
tests.
H
H
H
The
first
question
is:
do
we
want
a
common
set
of
tests
for
all
the
distributions?
You
could
probably
tell
them
what
my
answer
to
this
question
is.
The
benefits
of
having
a
common
set
of
tests
are
like,
first
and
foremost,
you
can
use
it
as
a
tool
to
sort
of
verify
that
this
is
an
open,
cfs
distribution,
because
by
definition
it
passes
all
the
same
tests
that
all
the
other
distributions
has
right.
H
If
we're
all
running
the
same
sets
of
tests,
then
we
have
a
more
distributed
sort
of
base
of
knowledge
right.
We
have
different
platforms
that
might
expose
a
bug
that
would
buy
latent
on
your
platform
and
get
the
benefits
of
the
fix
for
that
before
you
run
into
a
problem
maybe-
and
we
can
also
get
more
tests
from
other
people
which
is
really
him-
I
wasn't
really
able
to
come
up
with
any
cons.
I
think
that
there's
some
coordination
effort,
that's
required,
so
there's
an
investment
there,
but
I
think
doing
this.
B
H
D
H
H
H
H
D
I
I
B
G
G
H
It
right
it
was
a
conscious
decision
to
have
the
tests
live
with
the
source
so
that
as
the
source,
one
of
the
things
that
I
saw
in
sun
that
was
problematic
in
qa.
Was
that,
like
you,
have
these
two
branches
that
are
like
progressing
at
separate
rates
and
a
lot
of
times
more
often
than
I'd
like
to
admit
people
would
run
the
wrong
version
of
the
tests
on
the
newest
bits,
and
so
they'd
come
and
they'd
say.
Well,
I
just
wasted
two
days
of
my
life
and
I
have
these
50
000
failures
right.
D
B
G
H
C
H
A
great
place
for
it
and
an
answer
to
your
other
question,
I'm
sure
atf
for
qa
has
a
facility
for
this,
but
the
test
runner
basically
takes
a
configuration
file
and
right
now
I
have
one
for
the
lumos
and
one
for
delta,
specifically
and
as
it
happens,
they're
identical.
But
if
we
have
one
for
linux
and
bsd
and
then
that
defines
like
which
tests
are
on
each
platform
and.
D
H
H
Like
that,
how
do
you
account
for
well
I'm
running
these
tests,
but
this
is
a
crazy
experiment,
I'm
doing
in
gfs.
This
is
like
something:
that's
not
in
any
tree.
It's
not
something.
I
really
necessarily
plan,
I'm
just
playing
around
to
see.
If
you
know,
if
I'm
changing
interfaces
along
those
lines,
how
do
I
run
the
test
runner
at
all
if
it
expects.
B
H
B
Yeah
one
other
way
to
think
about
it.
Now
this
helps
because
in
my
mind
it's
like
is
there
any
having
their
part?
I
don't
see
it.
I
don't
can't
think
of
any
because
to
me
it's,
I
think
if
the
code
and
the
tests
are
together
that
whatever
version
I've
checked
out
yet
checked
out,
I
know
that
they're,
it's
compatible.
H
G
G
H
H
G
F
H
Yeah,
the
for
the
test
run
are
the
only
things
you
should
need
to
import
our
python,
that
you
have
and
and
then
some
work
too
number
three
yeah.
Oh,
that's
true,
yeah
ksh
and
fix
all
the
tests
to
understand
your
disk
names,
which
I
don't
have
any
idea
how
that
would
work,
but
it
seems
it
doesn't
seem
like
an
impossible
problem.
H
So
this
has
already
been
mentioned
earlier
today.
One
of
the
things
that
I've
talked
about
before
is
something
along
the
lines
of
what
was
described
earlier,
an
automated
facility,
where
you
just
say,
here's
my
repo
right
and
then
you
go
away.
It
pulls
your
bits.
It
builds
your
bit,
it
tests
your
bits
and
when
you
come
back
from
drinking
coffee
or
whatever
you
have
a
set
of
results
that
are
there
waiting
for.
F
C
C
A
A
F
J
What
you're
describing
there's
something
called
projections
like
github,
so
basically
you
integrate
your
income
positively
plug
into
changes.
You
can
basically
submit
a
pull
request
and
then
someone
on
the
github
site
basically
says:
go
and
test
this
pull
request
and
then
the
ejected
system
will
take
that
full
request
and
then
build
it.
And
then,
if
you
hook
in
and
test
test
it
and
then
only
if
it
passes
all
the
building
and
testing,
does
it
actually
do
the
work.
So
a
lot
of
people
do
ci.