►
From YouTube: State of OpenZFS 2019 by Matt Ahrens
Description
From the 2019 OpenZFS Developer Summit
slides: https://drive.google.com/open?id=197jS8_MWtfdW2LyvIFnH58uUasHuNszz
A
B
B
B
Can
you
hear
me
better
now,
okay,
good,
so,
first
of
all,
I
wanted
to
thank
some
outstanding
individuals
who
have
made
this
covers
possible.
They
probably
are
not
here
because
they're
outside
making
the
conference
possible,
but
thank
you
so
much
to
Karen
Karen
is
my
coworker
at
del
phix.
She
works
project
management,
so
she
got
all
the
catering
got.
Everybody
here
did
all
the
organizations.
So
thank
you
very
much.
Karen.
B
B
And
lastly,
thanks
to
favela
for
being
the
MC,
hopefully
I've
made
your
job
a
little
bit
easier
this
year.
We
do
have
a
more
break
time,
although
we
do
have
a
lot
of
short
talks.
We
have
a
lot
of
breaks,
so
hopefully
the
cut
the
hallway
track
will
be
just
as
beneficial
to
you
as
the
talks
themselves.
Thanks
Bob
l.
B
B
Next
del
fix
my
employer.
Thank
you
very
much.
Del
phix
I
know,
there's
a
lot
of
Duffing
screw
here
and
Intel
software.
Anyone
from
Intel
here
No.
Thank
you
very
much,
Intel
diamond
sponsor
this
year
and
OS
Nexus
Nexus,
yes,
hello!
Thank
you
very
much,
another
diamond
sponsor.
Next,
we
have
a
slated
gold
sponsors,
Argo,
Tech,
open,
drives
and
rock
top.
Thank
you
very
much.
Anyone
from
those
companies
here
I
know,
there's
a
few.
Yes,
hey
guys,
an
additional
gold
sponsors,
iock
systems
and
Nick
sent.
Thank
you
very
much.
B
B
So
first,
let
me
give
you
some
background
information
on
in
for
most
of
the
life
of
open
ZFS.
Where
has
the
code
come
from
where
the
new
features
come
from?
So
almost
all
of
the
new
feature,
development
has
happened
on
a
Limbo's
until
recently
and
there's
a
list
here,
some
of
the
new
features
that
have
gone
into
it,
and
then
there
are
other
code
repositories
for
ZFS
on
Linux,
on
FreeBSD,
on
Mac
OS
and
those
are
all
pulling
changes.
B
Porting
changes
from
the
most
to
the
various
platforms
and
and
also
contributing
back
to
bug,
fixes
and
stuff.
So
the
codes
flowing
in
all
different
directions
that
aren't
necessarily
shown
by
the
arrows
here
but
I'm,
showing
kind
of
the
primary
where
most
of
the
new
features
are
flowing
from
one
code
repository
to
the
next
and
we
created.
This
opens
the
efest
repo,
which
is
essentially
just
a
mirror
of
what's
in
the
Lumos,
as
a
way
to
ease
the
process
of
getting
changes
into
a
Lumos.
B
So
recently,
though,
we
talked
about
this
a
little
bit
at
last
year's
conference,
a
lot
more
new
feature.
Development
has
been
happening
on
ZFS
on
Linux.
So
if
you
look
at
like
the
past
year
or
two,
most
of
the
new
features
have
been
developed
first
for
ZFS
on
Linux,
and
then
those
have
been
ported
to
other
platforms
like
Lumos
and
FreeBSD,
and
did
you
know
that
this
works
well?
B
We've
been
putting
a
lot
of
effort
into
this
porting
and
making
sure
that
open
ZFS
is
great
on
every
single
operating
system,
but
porting
the
code
is
kind
of
a
pain.
It's
it's
work.
Swim
platform
is
always
a
little
bit
behind,
usually
when
the
code
is
when
some
feet
and
big
new
features
ported
to
another
platform
on
it,
you
know
there's
additional
eyeballs
people
are
looking
at
and
they're.
Saying.
Oh
like
what
about
this
little
thing?
B
What
about
that
little
thing
we
could
have
made
this
a
little
bit
better
in
some
way
and
it's
like
yeah.
That's
great
I
wish
that
you
had
told
us
that
when
we
were
doing
the
original
code
review
when
we
were
integrating
it,
so
then
you
know
there's
a
bunch
of
that
results
in
a
bunch
of
technical
problems
like
oh,
do
we
make
the
change
now
well
reporting
it
do
we
just
report
it
as
is
and
then
submit
patches
back
upstream.
In
any
case,
it's
like
a
lot
of
busy
work.
B
That
is
not
really
what
we
want
to
be
doing.
We
I
think
everybody
would
rather
be
developing
this
cool
new
features,
finding
and
fixing
bugs
and
not
dealing
with
like
whether
you
call
you
know
malloc
versus
K
malloc
versus,
like
some
other
thing,
so
one
of
the
goals
of
open
ZFS
from
day
one
was
to
have
one
code
repository
one
source
of
truth
that
just
works
for
lots
of
platforms.
B
So
we
don't
have
to
do
all
this
porting
and
worrying
about
differences
and
making
sure
that
there,
the
differences
are
minimized,
because
there's
just
one
open,
ZFS,
codebase
and
honestly
I
was
a
little
skeptical
that
this
would
ever
happen,
because
it's
a
huge
amount
of
work.
You
know
the
the
differences
in
functionality
between
say,
ZFS,
on
Linux
and
ZFS
on
illumos
or
FreeBSD
are
very
minimal,
but
there
are
like
the
number
of
lines
of
code.
Difference
is
quite
large,
and
so
it's
it's
a
huge
amount
of
work
from
a
code
base.
Point
of
view.
B
It's
a
huge
amount
of
work
from
a
process.
Point
of
view
of
how
we
do
development
and
there's
also
cultural
changes
right
like
each
each
operating
system
has
their
own
community
of
books
that
you
know
our
our
FreeBSD
folks
first
before
they
were
ZFS,
FreeBSD
folks
and
likewise
on.
You
know
in
Lumos
and
Linux,
but
the
FreeBSD
folks
have
stepped
up
and
they've
made
this
happen.
So
what
they've
done
is
taken
as
a
starting
point,
the
ZFS
on
Linux
repo
and
we're
in
the
process
of
making
that
work
on
FreeBSD.
B
So
one
code
repository
that
works
on
both
linux
and
freebsd,
and
it's
going
to
be
called
open
ZFS
for
the
next
and
FreeBSD
and
it'll,
be
one
so
just
like.
We
have
one
code
repository
on
ZFS
and
Linux
today
that
builds
for
like
Linux
kernel,
4.15
and
Linux
kernel
5
bed.
Oh
and
like
those
differences-
and
we
have
to
have
you
know
the
copilot
we
have
to
have
like
you
know
what
two
kind
of
a
key
code
to
deal
with
that,
but
you
know
it
needs
to
be
done.
B
The
same
thing
is
gonna,
be
true
of
you
know:
Linux
versus
FreeBSD,
where
you're
gonna
just
have
one
code
base,
and
there
might
be
a
few.
You
know
pound
defines
in
some
places
a
few
places
where
you
know
there's
two
versions
of
a
file,
one
for
Linux
one
for
FreeBSD,
but
those
should
be
very
minimal
and,
like
I
said
so,
this
is
a
goal
from
day
one.
So
you
know
why
hasn't?
It
happened
until
now,
aside
from
the
the
the
things
I
already
mentioned,
you
know
it's.
B
This
is
a
lot
of
work,
so
huge
huge
props
to
the
folks,
the
team
led
by
IX
systems,
engineers,
the
just
a
couple
of
examples
of
why
it's
so
hard.
So
first
of
all,
freebsd
uses
a
different
compilers,
so
they
recently
switched
to
LLVM
and
so
there's
lots
of
GCC
isms,
because
you
know
free,
illumos
and
and
linux
both
basically
just
used
GCC.
B
So
all
those
compiler
isms
need
to
be
factored
out,
and
you
know
we're
trying
to
do
things.
The
right
way.
We're
trying
to
not
just
have
pound
of
finds
everywhere.
You
know
macro
is
all
throughout
the
codebase
we're
trying
to
do
the
right
thing
like,
for
example,
when
there's
some
function
names
that
conflict
with
functions
that
are
provided
by
the
base
operating
system
in
freebsd
you're,
trying
to
just
saying
alright,
like
we're
just
gonna
bite
the
bullet.
B
Do
it
the
right
way,
rename
all
the
ZFS
ones
so
that
we
don't
have
to
worry
about
like
using
macros
to
pound,
to
find
things
to
change
the
names
of
things
or
like
scope,
header
files,
we're
trying
to
do
it
the
right
way
to
set
us
up
for
LAN,
long-term
success
and
I'll
talk
a
little
bit
more
about
that
in
a
few
slides
in
terms
of
the
status.
So
it's
a
work
in
progress
currently,
but
the
code
is
functional,
you
can
run
it
on
FreeBSD.
It
runs
the
test
suite
on
FreeBSD
and
doesn't
crash.
B
So
that's
like
a
lot
of
code
is
working
in
terms
of
up
streaming
and
actually
making
this
one
combined.
Repo
we've
already
had
about
more
than
60
pull
requests
landed
into
ZFS
on
linux,
repo
that
refactor
out
the
linux
specific.
That's
to
make
it
to
prepare
the
code
base
for
integrating
with
freebsd
there's
about
ten
that
are
currently
open.
B
There's
still,
a
lot
of
lines
of
code
left
the
land,
but
most
of
that
is
the
freebsd
specific
versions
of
like
the
the
ZPL
I
mean
other
higher
levels
that
interface
with
the
operating
system,
the
rest
of
the
operating
system
directly.
So
what's
left
to
do
like
I
said
the
code
basically
works.
So
there's
not
a
lot
of
new
code
that
needs
to
be
written
at
this
point,
but
it's
still
a
lot
of
stuff
that
needs
to
be
up
streamed
and
we
still
need
a
lot
of
code
reviews.
B
B
So
this
is
a
change
that's
coming
real
soon,
probably
before
you
know
that
any
of
the
freebsd
stuff
ships,
hopefully
by
the
end
of
the
year-
maybe
you
know-
maybe
we
can
get
together
at
the
hackathon
sort
out
all
the
details
it
there,
but
we're
just
basically
moving
the
ZFS
repo
that
is
currently
ZFS
on
linux
into
the
open.
Zfs
account.
So
you
know
the
URL
will
change
here,
but
it's
the
same
codebase.
B
You
know
what
we
have
in
ZFS
on
Linux,
but
but
we're
kind
of
acknowledging
that
we're
adding
freebsd
support
to
that.
But
the
ZFS
on
linux
or
as
eol
project,
is
not
going
away.
We're
just
renaming
the
codebase
to
reflect
the
fact
that
you
know
it's
going
to
be
the
ZFS
source
code
repository
for
not
just
Linux
but
also
FreeBSD,
and
maybe
potentially
some
others
in
the
future.
So
the
website
that
you
see
here,
you
know
that's
going
to
still
be
there.
The
mailing
list
will
still
be
there.
B
But
there
will
be
a
few
changes
so
today,
when
you
submit
a
pull
request
against
ZFS
on
Linux,
it
gets
automatically
built
and
tested
for
more
than
ten
Linux
distributions,
and
you
develop
on
your
district
choice.
You
don't
have
to
you,
don't
have
to
compile
your
code
on,
you
know
sent
to
a6
or
whatever,
but
the
project
ensures
that
you,
your
your
code,
works
on
all
of
the
supported
distres
of
Linux
in
the
way
that
we
do.
B
Oh
av
problems
is
this:
okay,
great
awesome,
so
show
of
hands
who
uses
ZFS
on
Linux?
Okay.
That
is
a
lot
of
people
who
is
using
the
master
branch
of
ZFS
on
Linux
in
production
like
your
product
is
deployed
like
not
many
people,
okay,
so
the
rest,
the
other
90%
of
you
presumably
are
using
releases
of
ZFS
on
Linux.
B
So
I
want
to
just
briefly
touch
on
this.
So
there's
several
like
distributions
of
ZFS
on
Linux.
So,
for
example,
Ubuntu
you
they
take
a
release
like
8.2
and
they
package
that
up
they
may
apply
some.
You
know
very
tiny,
minimal,
diffs
and
then
they
ship
it
in
you
know
a
bun
to
1804
or
whatever
version
they
are
shipping
going
forwards.
Freebsd
is
going
to
be
doing
basically
the
same
thing,
so
you
know
FreeBSD
13,
hopefully,
fingers
crossed
we'll
be
shipping,
a
release
of
open,
ZFS
and
so
freebie.
B
So
you
can
basically
be
thought
of
as
like.
A
distribution
of
open
ZFS,
similar
to
how
like
Ubuntu,
is
a
distribution
of
ZFS
on
Linux
and
that
next
major
release
will
be
called
open,
ZFS
2.0
for
linux
and
freebsd,
so
it
will
not
be
0.9.
It
will
not
be
0.
1
OH
it'll
be
open,
ZFS
dunno
for
linux
and
freebsd
and
it'll
be
coming
in
2020
month,
yet
to
be
determined.
B
Thanks,
so
what
what's
gonna
be
new
in
open
Ziva's
to
dato
relative
to
zero
to
eight
so
freebsd
support
and
whatever
else
is
in
the
master
branch?
So
there's
a
list
of
things
here
that
are
already
in
the
master
branch.
If
you
want
to
learn
more
about
them.
Most
of
these
we've
had
talks
about
them
at
this
conference
previously
in
previous
years,
or
one
of
them
coming
later
today
about
medicine
performance
and
additionally,
whatever
other
features
are
done.
B
B
Yeah,
so
the
question
was,
you
know
if
I'm
developing
a
feature
on
Linux,
because
that's
the
platform
that
I'm
running
or
care
about?
How
do
we
set
the
expectation
and
make
sure
that
it's
actually
going
to
work
on
FreeBSD
and
OSX,
and
all
the
other
platforms
that
are
supported?
I
think
that
this
is.
B
So
it's
a
big
part
of
it
is
cultural
which
is,
and
it's
the
job
of
the
leadership
to
enforce
that
culture.
So
to
give
a
smaller
example,
you
know
we've
experienced
this
today.
I
know,
you
know
said
that,
like
we
developed
some
feature
against,
you
know
a
bunch
of
1804
or
on
Linux
and
it's
running
you
know
some
very
recent
Linux
kernel
and
then
we
get
open
a
pull
request
and
it's
like,
oh
that,
like
some
tests
failed
on
sent
to
us
six,
that's
running
a
kernel.
B
That's
like
you
know,
I,
don't
know
how
many
Ritz
ten
ten
years
old
is
that
is
that
unreasonable
to
say
that's
ten
years
old,
all
right!
That's
ten
years
old
is
an
old,
colonel
and
we're
like
we
do
not
care,
but
we
do
care
about
getting
our
changes
upstream
so
that
we
aren't
stuck
with
maintaining
them
for
it
forever.
So
you
know
it's
a
part
of.
B
B
That's
why
you
need
to
get
it
working
and
also
helping
people
to
actually
do
that,
so
one
helping
them
by
with
the
automation
which
does
the
runs
and
actually
I,
think,
does
a
pretty
good
job
of
providing
results
that
you
can
actually
use
on
your
own
to
go
debug
with
the
test,
output
and
whatnot,
but
also
I,
know.
Brian
has
done
a
lot
of
work
to
actually
hold
people's
hands
and
be
like
yeah
I
didn't
work
on
cement,
Wes,
six
like
just
hold
on
I'm
gonna,
go
take
a
look
at
those
results.
B
I'm
gonna
go
like
dig
in
and
I
think
that's
something
that
project
leadership
is
gonna,
have
to
do
and
I
think
that
also,
you
know
we're
gonna
be
asking
folks
who
are
the
primary
consumers
on
FreeBSD
to
do
some
help
with
that
as
well.
So
it's
not
100%
on
the
pull
request
submitter
to
to
get
it
working
on
FreeBSD
like
he
needs
to
work
on
free
BC
before
it's
integrated,
but
you
know
we're
gonna
do
our
best
to
help
that
not
be
a
super
burden
on
on
the
poorest
submitter.
Hopefully
that
addressed
it.
B
Ok,
yeah,
yeah
I
mean
there's,
definitely,
ambiguity
there
and
I.
Think
it's
something
that
you
know
we're
gonna
have
to
try
and
see
how
it
works
and
I'd
like
to
this
end,
to
a
six
example
that
we
just
talked
about
like
we're.
Actually
yelling
sent
to
s6
in
zero
so
like
it
is
a
trade-off
and
it's
balanced
and
like
I,
think
that
you
know
FreeBSD
is,
is
here
to
stay,
but
I
think
that
there's
always
going
to
be
evolution
of
like
which
versions
of
FreeBSD
and
which
versions
of
Linux
and
whatnot
are.
B
But
yeah
at
the
end
of
the
day,
like
it
comes
down
to
the
like
maintainers
saying
like
no,
your
project
cannot
integrate
because
it
doesn't
work
on
platform
X,
which
is
supported,
which
is
a
supported
platform
and
like
we
have
to
draw
the
line
there
and
not
be
like.
Oh
sure,
you
can
just
add
it
if
def
Linux
and,
like
your
whole
new
feature,
isn't
gonna
work
on
previous
T
like
no
like
we're,
not
gonna.
B
B
Cool
so
I
just
a
couple
more
things
to
mention
diversity,
inclusion.
We
talked
about
this
a
bunch
last
year.
I
wanted
to
just
give
a
quick
update.
Since
then
we
have.
If
we
wanted
a
code
of
conduct,
we
we
actually
wrote
our
own
could
have
conduct
with
kind
of
heavy
influence
from
other
others
that
we
had
read.
B
Let
us
know
through
this
email
address
and
we
will
be
in
touch,
and
the
last
thing
I
want
to
mention
is
that
another
thing
new
since
last
year's
conference
and
also
prompted
by
discussions
at
last
year's
hackathon,
is
monthly.
Video
calls.
So,
every
month
we
have
video
calls
on
zoom',
where
we're
talking
about
proposed
new
features,
how
to
move
open,
pull
requests
for
words
and
other
things
like
that:
they're
recorded
there
on
YouTube
there's
a
Google
Doc
with
very
detailed
meeting
notes.
If
you
don't
want
to
watch
our
Lang
do
each
month.
B
So
you
can
join
us
for
this
month's
meeting,
which
is
next
week,
and
there
was
one
talk
that
was
scheduled
for
today.
Jason
Kings
talked
about
securing
the
cloud
with
ZFS
encryption.
Unfortunately,
he
is
ill
and
couldn't
make
it
today
so
he's
going
to
give
his
talk
at
the
meeting
next
week.
So
you
can
call
into
this
if
you
want
to
learn
about
how
to
use
ZFS
encryption
in
practice
and
or
if
you
want
to
talk
about
any
other
open-open
items.
So
that's
it.
Thank
you
very
much.