►
From YouTube: October 2019 OpenZFS Leadership Meeting
Description
At this month's meeting we discussed: zpool ddtload; xattrs status; OpenZFS repo; ZoF status; staging branch; release notes preview; early meeting time.
Details and meeting notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit
A
Alright,
let's
get
started
thanks
everyone
for
joining
us
for
the
last
open,
ZFS
leadership
meeting
before
the
developer
summit,
where
I
hope
to
see
many
of
you
three
weeks
from
yesterday.
If
you
have
not
already
registered,
you
should
really
do
that
very
soon.
We
are
almost
at
capacity
so
register
today
and
we'll
see
you
in
two
weeks.
A
We
have
a
few
items
on
the
agenda
and
we
may
have
time
for
additional
agenda
items
at
the
end,
if
folks
have
other
stuff
they'd
like
to
discuss.
So,
let's
start
off
with
zpool
DDT
load.
I
put
this
on
the
agenda
just
to.
Let
folks
know
that
this
was
a
new
sub
command.
I
was
proposed
by
will
Andrews,
don't
see
him
on
here,
I,
don't.
B
That
so
one
of
our
customers
is
using
dee
doop
extensively
and
has
a
very
large
DDT
table
on
the
order
of
100
some
odd
gigs,
and
they
found
that
after
a
reboot
for
the
first
couple
of
days,
right
performance
was
really
bad
because
I
haven't
do
random
reads
from
the
DDT.
So
we
created
a
sub
command
to
basically
initiate
prefetches
on
all
those
entries
in
the
DDT.
B
C
C
C
B
C
A
B
A
A
B
A
I
think
doing
it
as
a
sub
command
is
the
right
way
and
then
like
optionally.
If
we
want
to
have
some
convenience
of
automatically
running
this
every
time
you
do
an
import,
then
yeah.
Maybe
we
could
add
that
as
like
a
property
that
would
basically
kick
off
with
some
command
when,
when
you
load
the
pool
the
first
time.
C
B
C
C
C
A
E
Hi
Gordon
Ross
here
first
time,
hello,
everyone
just
just
briefly
I'm
trying
to
help
Andrew
out
I
had
a
discussion
with
him
today.
We're
not
ready
to
float
a
proposal
just
yet,
but
are
gathering
information.
If
anyone
knows
could
contact
people
for
him
on
to
ask
about
X
at
or
on
the
various
ZFS
implementations,
for
example
the
Apple
one
in
the
windows,
one
we're
one
of
the
things
we're
trying
to
include
as
a
survey
of
how
various
systems
are
doing
this
today,
I
think
I
spent
all
I
have
to
sit
offer
to
ask
today.
A
Thanks
on
OS,
X
and
Windows,
you
should
talk
to
your
grand
lemon.
He
he
basically
does
he's
like
the
one
man
boarding
machine
for
both
of
those
I
think
he
may
have
puts
it
on
the
mailing
list
about
that
he's
not
here
because
he's
in
Asia,
so
this
time
doesn't
work
for
him,
but
he's
usually
on
the
other.
The
two
out
of
the
three
calls
great.
A
Alright,
there's
a
Igor
I
saw
that
you
added
a
few
questions
on
to
here.
I'm
gonna
take
two
of
them
now,
the
other
ones
yet
to
about
integration
process.
Ideas
about
like
branching
in
I
assume.
This
is
visit,
that
those
questions
were
specific
to
ZFS
on
Linux,
slash
ZFS
on
FreeBSD,
using
the
zero
repo
and
I
think
those
would
probably
be
better
addressed
by
Brian
bounder,
who
couldn't
make
it
to
this
meeting.
I.
C
A
Well,
let's
see
I'll
take
this
one
first
I
know
about
this.
So
what's
the
status
of
the
open,
ZFS
repo,
it
hasn't
been
sync
with
the
Lumos
in
a
long
time,
so
I
may
as
well.
Let
you
guys
know
now:
we
are
planning
to
retire
that
rebo,
the
Oh
Quincy
fest
Rico,
that's
a
clone
of
us
and
we're
planning
to
kind
of
reinstate
and
open
ZFS
repoed.
That
will
be
basically
we're
going
to
move
the
ZFS
and
linux
repo
to
open,
ZFS
and
I.
A
You
know
acknowledge
that
that
repo
is
used
for
not
just
Linux
but
also
for
FreeBSD,
so
it
will
have
the
that
repo
won't
be
named
ZFS
on
Linux
anymore
it'll,
just
be
open
ZFS,
so
that
will
kind
of
take
the
place
of
the
of
the
current
Lumos
based
open,
ZFS,
repo
and
obviously
a
Lumos
will
continue
to
you
know.
Can
you
need
to
use
its
own
source
code
in
its
own
Lumos
github
account
in
processes
where.
C
A
So
the
existing
repo
I
think
will
will
get
rid
of
that
before
the
conference,
so
in
the
next
few
weeks,
I
just
listen
up
email
to
let
everybody
know
moving
over
the
ZFS
on
linux.
Repo
into
the
open
ZFS
will
happen
after
that
we
don't
have
any
real
deadline
aside
from
kind
of
the
schedule
about
making
freebsd
use
that
repo.
So
that
kind
of
ties
in
to
your
next
question
about
status
on
that,
yes,.
C
A
C
A
C
And
additional
testing
con
different
platform
will
be
helpful.
Try
to
find
some
issues,
for
example,
threads
faster,
anonymous
platform,
a
little
slowly
on
Linux.
Probably
some
issues
can
be
available
on
Linux
later,
but
we
can
try
to
find
it
on
another
platform,
a
very
fast
and
try
to
check
and
see
see.
Also
illumise
and
D
was
budget.
Another
was
contained
a
good
tool,
so
I
can
be
be
the
trace
where
we
can
try
to
check
what
we
need
trying
to
fix
on
other
platforms.
It
can
help
sort
with
chasing
nd
back
yeah.
A
A
A
A
D
God
is,
is
information
from
Matt
Macey,
which
is
he's
got
a
particular
set
of
things
he's
waiting
to
do,
which
include
async,
Co
W,
along
with
getting
the
various
things
reviewed
I've
been
doing
that
intermittently
as
well.
For
that
the
implication
was
once
that's
done.
The
other
part
is
then
getting
it
actually
into
FreeBSD
and
then
the
issues
there
have
to
do
with
replacing
what's
there
and
yet
keeping
these
stuff
for
the
boot
code.
A
A
Yes,
I've
taking
a
look
at
a
few
of
them
and
it's
definitely
good
to
be
aware
of
all
those
changes
that
are
coming
done,
all
the
reorganization
cool.
So
let's
move
on
to
the
next
topic.
So
Igor
did
you.
Do
you
want
to
talk
about
this
proposal
of
like
separate
branch
and
and
then
collecting
changes?
Yes,.
C
It's
one
idea
to
have
a
master
branch
to
be
a
stable.
What
I
mean
time
to
time?
We
can
see
some
issues
where
we
try
to
push
changes
to
master
branch
and
can
see
some
probably
not
good
result
with
tests
again
because,
for
example,
be
reviewing
a
changes
based
on
master
with
our
own
changes
for
one
commit
for
next
commit
and
several
commits
and
separately.
There
are
all
good.
If
you
try
to
merge
to
one
instance
by
changes
to
master,
we
can
see
some
not
good
result.
C
If
we
have
a
good
results
with
tests,
we
do
not
master
branch
and
take
a
final
builds
and
you
need
to
try
to
check
but
issues
we
can
try
to
find
commits
between
tags
and
analyze
it.
We
can
reduce
a
list
of
changes.
What
we
need
to
analyze.
If
you
try
to
find
a
some
bad
changes
or
some
not
good
changes,
it
is
like
a
year
for
discussion.
C
A
If
I
could
kind
of,
let
me
try
to
summarize
the
you're
trying
to
solve.
The
problem
is
that
you
want
to
be
able
to
submit
a
pull
request.
That's
based
on
some
commit
or
branch
that
has
been
more
thoroughly
tested
so
that
you,
like
the
the
the
test
failures
that
you're
getting
are
more
likely
to
be
ones
that
you
actually
introduced
and
not
ones
that
were
recently
introduced
by
other
commits.
C
Problem,
if
you
can
see
issue
with
several
cars
in
one
built,
every
PR
can
produce
a
good,
build
and
good
test
results.
But
if
you
try
to
merge
several
cars
together,
they
can
produce
a
panic
or
some
not
good
result,
and
we
can
identify
it
by
checks
on
separate
additional
branch
and
commit
to
master
only
tasted
list
of
cars,
not
every
car,
but
try
to
collect
additional
cars
on
additional
branch,
probably
weekly
or
bi-weekly
two
weeks
and
merge
one
by
one
commit
0pr
snow
monster.
A
A
C
C
C
A
I've
also
noticed
that
problem
and
the
solution
makes
sense,
I
think
that
I,
you
know
the
goal
has
been
that
you
know
the
master
branch
is
always
ready
to
test.
Yes,
it's
ready
to
go
and
there
aren't
any.
You
know
and
failures
and
that's
a
great
goal,
and
we
have
not
always
achieved
that
I.
This
is
speaking
specifically
of
the
ZFS
on
Linux,
probably.
C
A
So
I
think
it's
it's
kind
of
a
question
of
like
how
much
work
do
we
want
to
put
in
to
to
you
know
to
solve
this
problem,
and
I
personally
would
not
be
the
would
not
be
putting
in
network,
but
you
know
maybe
Brian
or
other
folks
at
Livermore
might
be
interested
in
doing
that.
It
sound
like
you,
had
some
conversation
with
Brian.
What
what
was
his
doing
to
kind
of
summarize
his
reaction
is
Jake.
Okay,.
F
One
thing
that
I
wanted
to
bring
up
is
I
think
the
challenge
with
the
staging
gate
idea
and
like
is
that
you
may
be
making
changes
to
code
that
will
have
to
merge
with
things
that
aren't
in
the
staging
gate.
So
any
testing
you
do
may
not
necessarily
you
know,
be
completely
valid,
because
once
you
get
ready
to
integrate
you're
going
to
be
having
to
deal
with
other
changes
that
are
in
and
potentially
retesting
and
find
yourself
in
a
situation
where
you're
having
to
deal
with.
C
F
A
C
A
C
Tried
to
find
out
that
probably
my
issue
or
some
others
for
working
on
integration,
because
we
are
using
some
deep
cherry
peak
of
some
changes
from
master
branch
to
our
own
branches
and
we
try
to
think
about
it's
a
stable.
But
time
to
time
we
can
see
that
master
branch
can
contain
some
issues
and
at
this
moment
I
try
to
wait
about
one
week
and
take
a
look
time
when
master
branch
should
will
be
tested
by
some
others
to
reduce
my
issues
with
nurse.
A
A
You
know,
tanks
are
in
commits
and
then
say,
like
you
know,
every
week
which
I
get
a
commit
and
then
each
of
those
will
kind
of
get
tested
and
Lhasa
people
are
running
last
week's
build,
and
then
maybe
you
know,
people
who
want
more
stability
could
wait
to
hear
that
go
like
last
week's
build
was
a
little
rough
I'll
wait
for
the
next
one
or
I'll
go
back
to
the
one
I
think
you
know
something
like
that.
That's
sort
of
more
lightweight
than
actually
having
additional
branches.
A
A
D
D
Tenable
problem
a
way
to
approach
the
problem.
We
are
too
diverse,
you're
talking
about
too
many
different
things.
This
is
pretty
much
guaranteed
you
just
bogged
down
and
misery
and
be
forgotten
about.
I
would
suggest
if
we
want
to
have
the
concept
of
semi-stable.
This
is
a
thing
to
discuss
in
person
with
a
bunch
of
people
at
the
dev
summit.
Senses
coming
up
so
so
I.
C
Found
additional
examples:
we
try
to
ask
developers,
try
to
rebase
the
latest
master
branch
and
try
to
change
test.
His
changes
before
and
before
most
from
master
branch
and
developer
can
see
issues
not
related
to
his
changes
because
they
try
to
replace
the
latest
master
and
master
can
contain
some
issues.
You
know
I
mean
I.
Try
to
reduce
this
problem.
C
A
It's
definitely
a
problem.
I
think
that
the
question
is
how
much
of
that
problem
with
like
creating
additional
branches,
releases,
etc,
type
of
process
versus
how
much
should
we
address
this
problem
by
better
pre
integration,
testing,
better
processes
around
like
reverting
changes
that
are
bad
more
quickly
and
things
like
that,
because
you
know
the
end
of
the
day,
like
it's
all
we're
all
trying
to
write
software
now
introduced
bugs
in
to
test
our
software
thoroughly
and-
and
this
thing
to
say
about
all
those
problems
with
process.
F
A
C
You
kind
of
talk
a
little
bit
more
about
what
you
mean.
Yes,
it's
probably
some
planning,
because
if
you
try
to
organize
for
platform
owners
take
a
vision,
what
we
have
plans
for
releases
in
ZFS
code,
if
can
helps,
for
example,
I
won't
release
the
deals
as
a
platform,
but
I
would
like
to
know.
Plans
of
ZFS
releases
try
to
prepare
an
Xcode
drop.
What
I
can
use
with
my
platform
release?
Is
it
partly
will
be
integrated
of
current
changes
or
I
can
wait
a
little
with
additional
service
changes?
C
What
can
be
included
and
provide
some
platform
update?
It's
an
idea
for
probably
CCP
weekly
bi-weekly,
where
we
try
to
collect
a
list
of
changes
between
platforms,
and
we
can
be
in
sync
between
platforms
what
they
try
to
resolve
issues,
ways
it
on
a
list
of
issues
on
site.
Probably
some
platforms
tried
those
internal
issues
and
can
provide
some
additional
information
or
drive
of
Oban
additional
issues
on
open
the
FS
sites,
and
we
can
be
in
sync
with
all
other
contributors
or
what
holes
with
say:
visibility,
yeah,.
A
C
C
A
I
mean
I
think
that
that's
actually
I
think
it's
a
good
idea.
You
know
we'll
have
to
talk
to.
You
know
the
folks
at
Livermore
who
are
doing
all
of
that
release.
Work
force
to
convince
them,
but
I
think
that
if
we
pushed
as
something
like
hey,
let's
have
a
draft
of
the
release
notes
and
it
can.
It
can
have
here's
the
things
that
are
like
you
know.
A
We
know
are
gonna,
be
in,
and
then
here's
like
the
next
this
this
project
we
think
is
gonna,
be
in,
and
so
you
know
anybody
who's
wondering
what's
going
to
be
in
the
next
major
release
or
the
next
minor
release
could
check
that
in
--see
from
that
kind
of
make
a
judgement
of
like
oh
well
they're
waiting
for
this
Jagan
project.
That's
gonna
take
a
long
time,
so
I'm
not
gonna,
wait
for
the
next
release
or
whatever
information.
A
I
think
that
we
definitely
need
to
get
better
about
communicating
about
branching
and
the
release
cycle
and
what
goes
into
bread.
What
goes
into
the
next
releases
so-
and
this
is
something
too
I
I-
am
interested
in
working
on
and
making
sure
that
it
happens.
So
yeah
I'll
work
with
Brian
and
other
folks
to
try
and
starting
with
the
next
major
release
at
least
have
a
process
that
is
more
transparent
in
kind
of
communicates
better.
What's
going
on
without
having
to
like,
you
know,
ask
Brian
every
three
weeks
what's
happening
with
Noda?
A
C
I
have
some
example
about
zero,
a
to
tag.
Where
was
using
a
smaller
list
of
changes?
What
was
on
master
because,
for
this
tag,
a
list
of
commits
was
define
it
by
Brian
and
you
or
some
others
pickles,
and
some
FreeBSD
changes
with
a
little
quad
for
files,
not
included.
It
is
why
I
am
interested
in
some
process
for
planning
where
we
can
identify
a
list
of
changes
based
on
open
issues,
bug
tracker
what
we
plan
to
include
to
next
Cathedral
yeah.
A
Which
would
be
fine
with
me
so
just
to
remind
folks
we
we
do
like
to
we
have
like.
We
have
a
pattern
of
three
meetings.
We
have
two
that
are
at
the
later
time,
which
works
well
for
folks
were
better
for
folks
in
Asia,
and
then
we
have
one
that's
at
this
earlier
time.
That's
this
week,
that's
at
an
earlier
time,
that's
better
for
folks
in
Europe.
A
B
A
A
A
A
A
B
A
A
F
Thought
I
thought
there
was
actually
something
on
the
gol
wiki.
The
wiki
has
older
builds
and
it's
not
super
clear
for
belated.
Okay,
because
I
thought
I
I
seem
to
recall
that,
like
they
tried
to
build
like
certain
packages
and
kind
of
store
them
there,
but
maybe
they're
not
keeping
up
to
date.
That's
my
impression
it
would
be
the
one
to
talk
to
you.
A
Brian
or
otherwise
I
mean
Brian
might
or
might
not
know
you
might
try
on
those
FS
oolitic
nailing
lips,
because
there's
just
so
many
people
that
are
using
as
the
offensive
links
there
I'm
sure
that
there's
somebody
who's
like
you
know
using
exactly
the
same,
really
that
you
are,
and
that
has
you
know,
wanted
to
run
master
or
the
latest
soda
eight
and
they
can
tell
you
like,
oh
yeah,
I
built
it
from
rpm
screws,
the
commands
that
you
need
or
downloaded
from
some
random
dudes
website
and
go
oh
cool.
Thank
you.
That's
all.
A
E
Now,
because
systems
vary
in
all
of
these
areas,
you
may
lose
some
or
any
of
these
things.
It's
just.
It
came
up
while
we're
looking
at
what
are
the
various
things
that
the
systems
treat
differently
and
all
all
the
systems,
many
of
the
systems
we
treat.
We
look
at
treat
various
of
these
things
differently,
so.
A
Is
it
that
they
I
think?
Well,
let's
see
my
question
is
so
forth.
Let's
say
da
style
attribute
bits,
for
example,
is
the
issue
that
that
some
platforms
don't
support
those
attribute
bits.
So,
like
you
take
it's
just
you
take
a
pool
from
illumise
where
you
can
set
them
and
observe
them,
and
all
that
stuff
you
take
it
to
another
platform,
and
then
it
just
ignores
that
das
attribute
bits.
E
Yeah,
it's
mostly
that
the
some
of
the
platforms
ignore
them
so
I'm
trying
to
be
cautious
about
pointing
fingers
of
blame
about
who's,
throwing
away
information
where
at
this
point
and
just
try
and
document
what
we
have
said,
but
it's
just
I
just
wanted
to
give
people
heads
up
to
this.
This
stuff
is
also
relevant
to
the
Atkins
case.
Yeah.
A
That
would
be
like
wrong
because
we've
decide
you
know
two
columns
I
just
have
decided
to
store
the
apples
in
two
different
incompatible
ways
where
really
they
should
have
uses
dim
light.
It
sounds
like
we're
not
in
that
situation
as
far
as
Ackles
and
the
daus
attribute
bits
as
far
as
we
know
yet,
on.