►
From YouTube: July 2020 OpenZFS Leadership Meeting
Description
At this month's meeting we discussed: OpenZFS Conference dates; ZFS send compatibility with ZSTD; OpenZFS 2.0 release plans; forced pool export
Full meeting notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit#
A
All
right
cool,
let's
get
started,
welcome
to
the
July
20/20
of
the
open,
ZFS
leadership
meeting.
We
have
just
a
few
things
on
the
agenda
today.
So
if
you
have
I
see
someone
else,
that
was
typing
a
new
agenda
item,
so
great
we'll
probably
have
time
for
that.
I
wanted
to
get
started
by
reminding
folks
about
the
opens
best
developer
summit
I
sent
out
an
email
update
on
that
yesterday.
So
we
made
a
couple
changes
to
the
dates
we're
pushing
out
the
date
of
the
conference
by
one
week
to
avoid
a
scheduling
conflict.
A
A
If
you
have
not,
registered
registration
is
open.
It's
free.
More
importantly,
I've
pushed
out
the
deadline.
More
importantly,
for
this,
for
this
audience,
I've
pushed
out
the
deadline
for
submitting
talks
by
two
weeks.
So
you
have
almost
two
weeks
left
to
submit
a
talk.
We
could
use
a
lot
more
talks.
We've
had
a
few
a
few
good
ones.
I
have
a
few
ideas.
There
are
a
few
people
that
I
have
still
left
to
bug
about
my
ideas,
but
there's
there's
lots
of
time
still
available.
A
So
if
you
have
done
cool
stuff
with
ZFS,
if
you're
working
on
developing
a
new
feature
that
you
want
talk
about,
get
some
feedback
on.
If
you
have
used
a
ZFS
in
a
unique
situation
and
maybe
discovered
some
interesting
behaviors
that
that
folks
might
not
be
aware
of
those,
those
are
all
whole.
Those
would
all
make
for
great
talks.
B
So
I've
been
working
on
finishing
up
that
set
of
patches
that
I
started
quite
a
few
years
ago,
and
the
biggest
question
right
now
is
how
to
deal
with
ZFS
end
compatibility
specifically,
so
that
you
know,
wouldn't
accidentally,
creates
a
stream.
They
won't
be
able
to
receive
the
way
we've.
It
seems
we've
always
done
it
is
that
new
features
are
guarded
by
a
new
flag
so
that,
if
you
know
the
exact
ZFS
send
command
you've
a
non
0.7,
you
started
running
a
0.8.
B
It
would
still
be
receivable
on
a
machine
that
was
used
to
receiving
snapshots
from
0
to
7
and
how
to
deal
with
that
with
said
standard.
One
of
the
trickier
parts
is
that
if
you
use
standard
compression
on
a
data
set,
we
compress
the
embedded
block
pointers
using
Zed
standard
resident
ELLs
at
four
and
the
embedded
block
pointer
sin
stream.
Flag
only
implies
support
for
ELLs
at
four,
and
we
have
a
couple
of
options
there.
B
We
could
change
it
and
only
compress
those
blocked
by
embedded
black
learners
with
elves
at
four,
even
when
you
asked
for
a
different
compression
algorithm,
although
that
also
seems
slightly
weird,
but
maybe
that's
what
embedded
block
pointers
mean
and
we
would
need
you
know
a
different
feature
flag
for
says,
standard,
embedded,
block,
pointers
or
something,
and
then
even,
if
you're
doing
a
send
with
just
C
for
compressed
again.
That
mostly
assumes
that
you
know
you're
using
one
of
the
supported
compression
algorithms
and
there's
no
way
to
say
well
what
about
this
newer
one?
B
Even
if
you
don't
the
other
problem
is,
if
you
have
the
properties
included
in
the
env
list,
then
you
know
you
can
end
up
setting
a
compression
or
asking
the
receiving
side
to
set
a
compression
properties.
That's
out
of
the
range
of
its
enum.
Even
if
you
don't
use
the
C
flag
and
actually
aren't
sending
any
of
the
grass
blocks.
You're
still
saying
you
know,
compress
equals
sixteen,
which
is
off
the
end
of
the
the
enum
on
a
0.8
install.
B
B
And
it's
especially
hairy
with
says
Center,
because
we
used
the
upper
bits
to
store
the
level,
so
it's
16
and
some
other
number.
So
it
ends
up
for
like
15,000
or
something
yeah,
and
you
know
that
same
thing,
I
guess
would
have
applied
to
when
we
added
you
know,
sha-512
and
and
skiing,
and
all
the
other.
B
B
D
B
A
Yeah
I
think
that
those
are
a
lot
of
good
points
and
I
think
we'll
probably
have
to
think
about
the
details
of
each
one
of
them
separately,
like
each
of
those
ways
that
it
could
show
up,
like
properties
versus
embedded
blocks
in
compress
blocks
and
etc.
I
think
I'd
like
to
propose
so
two
principles,
one
whatever
we
send
the
receiving
side
should
be
able
to
tell
whether
it
supports
it
and
then
give
you
a
like
non
horrible
error
message.
Yes,.
B
A
B
A
A
So
that's
principle,
first
principle,
but
the
same
principle
I
would
propose
is
a
little
bit
of
a
departure
from
what
we've
done
in
the
past
and
I
would
I
think
that
we
should
seriously
consider
making
the
default
behavior
be
like
if
you're
like,
if
you're
already
saying,
to
send
compress
blocks
or
send
embedded
blocks,
then
we
send
them.
However,
they
are,
and
we
don't
give
like
a
finer
grained
granularity
to
at
least
like
by
default.
You
don't
have
to
specify
any
finer
grained
like
which
compression
algorithms
are
allowed
to
be
contained
in
the
sense
stream.
A
The
reason
is
that,
like
we've
seen
a
lot
of
problems
where
the
default
like
we've
we've
created,
this
super
backwards-compatible
system,
which
is
rarely
taken
advantage
of
and
has
like
occasionally
resulted
in
people
shooting
themselves
in
the
foot
and
I
think
often
resulted
in
people
not
getting
the
not
people
seeing
sub
optimal
performance
and
behavior
of
ZFS
n.
Like,
for
example,
you
know,
I
just
run
ZFS
send
and
send
my
thing
to
another
system
and
I'm
hanging.
All
this
like
decompression
and
recompression
cost.
B
B
D
B
B
Branch
right
now
it
would
still
you
know
your
send
would
be
0.8,
but
not
necessarily
there
that
seven,
unless
she
specifically
asked
for
that
yeah,
but
you
wouldn't
automatically
get
locked
there
just
because
you've
started
using
a
new
feature.
So
would
let
us
have
a
more
modern
default?
I
could
keep
increasing
while
still
letting
people
you
know
kind
of
do
groups
of
options
rather
than
having
to
specify
every
feature
individually,
just
be
like
whatever
everything
supported
in
2019
yeah.
A
D
D
A
B
A
A
A
B
A
A
B
A
E
I'm
not
specific
to
the
standard
stuff,
I
think
the
solution
that
we
came
up
with
is
fine,
but
if
we
have
time
to
talk
about,
the
compat
thing
that
we
talked
about
with
regard
to
ZFS
end
is
like
what
would
go
into
that
compared
feature
of,
like
said,
because
not
everything
is
strictly
like
progress
that
you
can
just
always
opt
into
and
find
with
it.
There
are
options
that
you
only
want
in
certain
situations.
B
A
If
we
have
this
mechanism,
then
it's
also
a
lot
easier
to
do
the
even
better
thing
when
we
add
new
compression
algorithms,
for
example.
Right
because
then
you
know,
the
compat
equals
2019
would
know
like
oh
yeah,
I
can
send
compress
blocks,
but
only
you
know:
legacy
and
lz4,
not
Zee
standard
right
and
like
managing
the
fine
grain.
This
of
that
would
not
be
difficult
if
we
had
that
infrastructure.
A
E
A
B
A
B
A
B
A
B
B
B
A
I
think
that
we
want
to
avoid,
like
we've
done,
a
bad
job
with
that
I
think
we
want
to
avoid
that
if
we
can't
going
forward
I
think
that
you
know
Christian
on
your
question
of
the
kampang
like
doing
the
like
compat
for
zpool
feature.
Flags
is
much
more
compelling
because,
as
far
as
I
know,
they
are
all
strictly
better.
Like
there's,
you
know,
there's
no
reason
to
have
them
off
aside
from
compatibility
and
there's
a
whole
bunch
of
them.
It
is
not.
B
B
I
think
currently
should
not
get
certain
features
you
have
to
either
you
know
manually
specify
which
ones
you
want
on
and
off,
or
do
like
a
V
28
and
then
try
to
upgrade
or
something.
And
it's
a
bit
it's
a
big
point,
because
yeah
I
know
that
came
up
recently
with
I
think
people
using
the
new
tune
as
core
beta
or
whatever,
because
it's
based
on
the
master
branch
has
the
base
map
v2
stuff,
and
so
it
can't
be
imported
on
a
0.8,
Linux
edifice
and
Linux
the
defaulting
to
newer.
But.
A
A
B
E
A
F
They've
been
times
when
people
have
used
City
fests
in
streams
like
tah,
so
there's
a
little
bit
more
impetus,
I
think
to
not
always
move
this
slider
forwards,
necessarily
like
the
back
end
of
it.
That
is
like
I
think,
while
you
can
imagine
rolling
the
pool
versioning
stuff
forward,
you
know,
as
we
sunset
old
software
portions
I,
think
as
an
interchange.
Format
like
the
stability
and
shape
I,
think
it's
a
slightly
different
consideration
under
some
conditions.
Anyway,.
A
Yeah
I:
don't
think
that
with
I,
don't
think
that
we've
proposed
son
like
actually
Sun
setting
any
of
the
zpool
version
so
like
you,
can
create
a
version.
1Z
pull
with
the
latest
software
and
like
everything,
should
work
at
least
as
well
as
it
did
15
years
ago
and
with
the
sense
streams.
I
think
the
only
thing
the
only
changes
that
we
made
there
are
to
remove
the
dee-do
dee-do
yeah.
F
D
G
A
A
B
E
I
said
one
other
idea
like
from
a
to
developer's
point
of
view,
in
particular
from
zero
Pat's
point
of
view,
where
we
have
a
demon
running
on
both
sides
and
communicate
I,
don't
know
that
what
I
would
actually
want
is
a
thing
like
a
command
that
I
can
run
on
the
receiving
side.
That
gives
me
an
opaque
talk,
nor
an
envious
encoded
in
something
that
just
declares
what
features
are
available
on
the
receiving
side,
and
then
you
paste
that
command
to
the
sending
side,
and
this
is
like
definitely
compatible
with
the
receiving
side.
So.
E
B
B
D
B
A
B
A
A
B
A
B
The
zpool
feature
flight
doesn't
get
switched
from
enabled
to
active,
and
then
you
can
import
it
on
0.8
or
0
that
7
machine
and
then
set
a
festival
panic
when
you
try
to
do
that
fest
list
or
something
because
you
have
this
compressing
them
that's
outside
of
the
develop
range
and
we
decided
the
best
thing
to
do
is
try
to
enable
the
feature
flag
as
soon
as
you
set
the
property
so
that
you
know,
if
you
do
need
to
unset
it.
You
can
still.
B
F
A
B
A
A
D
It's
just
asking
because
right
now
we're
approaching
two
nos
12
base,
2
3,
B's
d12
release
in
couple
months
and
then
Phoebe's
D
also
is
preparing
to
pull
something
into
head
and
doing
boss
from
master
is
not
very
nice,
as
was
told
Freddie's
from
capita
bility
points,
so
at
least
put
in
some
landmark
would
be
nice
Oh.
In
addition
to,
of
course,
some
features,
stabilization
and
quality
stabilization.
G
So
the
bat
mentioned
the
plan
we
talked
about
was
basically
to
target
the
middle
of
August
and
kind
of
branch
there.
That
will
be
the
200
release
and
start
stabilizing
on
that.
So
we're
trying
to
have
all
the
major
features
in
by
then
d
standard,
any
other
major
stuff
for
FreeBSD
that's
needed
would
be
like
be
great
if
we
get
that
wrapped
up
before
we
cut
a
branch,
but
we're
kind
of
targeting
middle
of
August
I
mean,
though
middle
sounds
great
for
us
for.
D
A
Yes,
so
I
think
we
know
only
real
things.
I
think
that
we
are
officially
not
holding
the
release
for
any
more
features,
and
you
know
if
it
gets
in
that's
great
stuff
gets
in
that's
great
and
the
main
thing
is
just
FreeBSD
stabilization.
You
know
getting
that
getting
all
the
lasts
bugs
and
you
know
known
compatibility
issues
and
little
missing
integrations
done
and
then
we'll
we'll
cut
well.
A
So
what
my
understanding
is,
what
will
happen
is
a
little
bit
different
than
what
we've
done
in
past
releases,
which
is
like
in
in
mid-august
we'll
create
a
new
branch
off
of
the
tip
of
Master.
That
is
the
to
do
and
that
the
master
branch
will
remain
open
for
you
know
whatever
new
features
or
things
that
people
want
to
throw
in
and
we
will
have
to
work
will
have
to.
A
G
A
A
G
D
Of
that
in
place
now,
oh
wait
still
collecting
smallish
things
here
and
there
maybe
some
of
smaller
things,
not
yet
upstream
I,
don't
remember
something
like
more
Oh
better
shift
hand
in
from
vbg
was
not
upstream.
It
may
be
some
other
things.
The
biggest
thing
we
have
in
FreeNAS
that
would
like
top
stream,
is
I,
think
open,
right,
I.
Think
Jim,
you
is
a
spectra.
Logic
work
that
Matt
is
currently
rebasing
and
improving.
D
D
You
know,
of
course,
we
we
have
such
goals
so
we're
trying
to
coordinate
all
things
together
to
release
same
time
from
as
12
or
3
BSG.
Oh,
maybe
we'll
see
how
it
goes
up
streaming,
but
at
least
now
we
have
already
images
of
unified
like
if
I
chose
trees.
So
you
can
build
the
FS
out
of
the
bait
system,
not
from
ports,
so
more
people.
They
are
able
to
test
it
and
we
put
more
people
to
not
see
things
as
a
kind
came
it
locally.
A
G
Have
but
but
actually
need
to
have
yeah
I
think
there
was
a
github
project
created
to
track
a
lot
of
this
stuff,
but
it
may
not
be
totally
up
to
date.
We
were
tracking
like
missing
previously
functionality
there
that
we
considered
a
regression.
We
should
go,
look
at
it
and
update
it,
but
that's
where
I
would
look.
Ok,.
D
A
A
E
E
B
Whereas
currently,
in
that
situation,
you
know,
if
you
tried
to
do
ZFS
list
or
something
on
suspended
pool,
you
can
get
stuck
with
something
holding
the
spa
names
face
lock
or
something,
and
a
lot
of
stuff
won't
work
on
the
pool.
That's
perfectly
fine
because
of
the
other
pools
suspended,
because
it's
disk
went
away
or
whatever,
and
so
hopefully,
in
the
next
few
months,
we'll
have
something
to
show
as
a
pull
request,
great
with
a
bunch
of
extra
tests
and
so
on.
Added
for
it.