►
From YouTube: December 2018 OpenZFS Leadership Meeting
Description
We discussed strategies for porting features to all the platforms.
Agenda and meeting notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit?ts=5bb3b66c
A
Welcome
everyone
can
folks
cheer
me:
okay,
yep,
yes,
awesome!
Thank
you
so
welcome
to
the
wind,
ZFS
leadership.
Meeting
we're
gonna
be
having
a
one-hour
meeting
today.
I
know
the
reminder
that
I
sent
out
I
still
had
the
30
minute
time
on
it.
But,
as
we
discussed
last
meeting,
we're
gonna
go
for
an
hour
today.
I
bought
dyes
if
anybody
needs
to
drop
off
after
the
half
an
hour.
A
So
there
are
a
bunch
of
interesting
things
to
talk
about
in
the
agenda,
so
there's
kind
of
three
categories:
I
think
that
we
can
talk
about
today.
One
is
continuing
to
talk
about
the
ideas
from
this
from
the
spreadsheet,
the
the
projects
from
the
spreadsheet
and
who's
gonna
own
porting
them
to
the
different
platforms.
A
The
other
is
kind
of
continuing
the
discussion
that
we
started
last
time
about
kind
of
the
big
picture
of
porting,
and
if
we,
if
we
want
to
be
doing
things
kind
of
piecemeal,
project-by-project
versus
like
trying
to
take
every
change
in
order,
you
know
from
Linux
to
the
other
platforms
and
then
the
third.
Is
there
a
bunch
of
interesting
topics
that
were
brought
up
and
put
onto
the
agenda
in
the
past
month,
including
one
that
I
think
would
be
interesting
to
discuss
today?
A
A
Okay,
I'll
assume
not,
but
I
think
that
he
brought
up
some
good
points,
even
though
I
kind
of
disagree
with
the
is
overall
suggestion,
I
think
that
it's
definitely
a
worthwhile
problem
to
try
to
address
so
I
think
we
could.
We
could
discuss
that
among
the
other
ideas
that
were
on
the
agenda.
So
since
we
have
an
hour,
we
probably
have
time
I
think
to
do
most
of
these
do
folks,
I
guess
the
maybe
the
more
contentious
one
might
be
the
high-level
picture
of
how
we
want
to
do
porting
from
between
the
various
platforms.
A
So
why
don't
we
start
off
with
that?
If
folks
have
opinions
or
if
it's
kind
of
still
status
quo
same
as
last
meeting,
then
we
can
kind
of
skip
that
and
go
on
to
the
particular
features.
So
I'll
open
the
Florida
folks
who
want
to
discuss
like
if
we
should
even
be
talking
about
each
individual
feature
versus
if
we
should
be
focusing
more
on
how
to
get
like
every
every
commit
onto
every
platform
and
what
the
process
is
for.
That.
B
A
A
I
think
so
too
I
think
I
think
that
it's
more
complicated,
mostly
from
a
is
more
complicated
to
do.
It,
takes
more
work
to
do
I,
don't
know
how
much
how
much
discussion
we
need
to
you
know
I
think
it's
a
lot
of
hard
work
to
just
go
back
through
and
look
at
like
every
commit
from
Linux
and
FreeBSD
and
hey.
A
Do
we
have
that
on
illumos,
for
example,
or
you
know,
Shawn
I
think
you're
coming
from
free/busy,
so
go
back
and
look
at
every
commit
from
Linux
then
do
we
do
we
have
that
on
FreeBSD?
If
not,
then
do
the
port
resolve
other
conflicts?
I
think
that's.
If
somebody
is
going
to
step
up
to
do
that
work,
then
that's
great
and
I
think
then
we
can
kind
of
track.
This
progress,
you
know
more
chronologically
versus
feature-wise.
C
I
think
for
Lumos
we're
at
least
in
the
work
that
we're
doing
at
joint
we're
looking
for
at
our
rather
sorry
looking
at
seeing
it
as
a
diff
minimization
effort,
rather
than
so,
rather
than
the
path
dependent
approach.
We
sort
of
look
at
all
the
commits
that
have
happened
and
try
to
keep
up
with
each
one
of
those
I.
C
So
we're
probably
going
to
look
at
like
pick
a
specific
state
of
the
0l
tree
and
then
our
current,
like
a
Loomis
guide
state
and
do
a
big
diff
against
that,
and
then
try
and
you
know,
like
the
moral
equivalent
of
getting
a
highlighter
and
trying
to
start.
These
parts
seem
like
they're
related
and
we
might
not
end
up
pulling
the
structure
and
commit
four
commits.
C
A
So
in
that
case
it
sounds
like
you
know,
you
know
prominent
folks
from
the
most
and
FreeBSD
are
interested
in
doing
at
that.
That
way,
our
different
differently
than
just
like
taking
each
project,
the
way
that
I'd
kind
of
been
going
through
the
feature
matrix
so
sounds
like.
Maybe
we
should
I
think
it
still
worth
continuing
to
track
what
features
are
available
platforms
using
a
spreadsheet,
but
it
might
not
be
as
useful
as
a
good
views
of
our
time
to
kind
of
go
over
each
each
one
of
those
and
try
to
assign
a
Hohner.
D
Probably
one
idea
about
some
release
engineering:
it's
if
we
have
some
different
projects,
we
need
to
know
states
of
ZFS
between
different
platforms,
yes,
and
for
some
management,
the
same
components
on
different
projects.
We
need
to
know
probably
some
label
or
tag
and
how
it
compare
with
the
same
code
and
components
in
other
platform,
a
primary
issue.
At
this
moment
it
is
different
fishes
and
some
different
code
base
between
platforms,
illumise,
Linux,
FreeBSD
and
a
first
step.
D
Probably
it
can
be
tried
to
synchronize
a
teacher
said
if
it
is
possible
if
it
is
impossible,
try
to
identify
the
same
teacher
between
different
platforms
and
probably
agonized,
step
by
step
of
synchronization
of
the
species
between
platforms
and
organized
automation,
testing
of
the
stitch
on
different
platforms.
We
used
this
logic
on
motorola
project,
where
we
do
some
integration
on
different
platforms,
where
we
can
identify
a
different
components.
D
I
think
we
can
try,
probably
split
some
feature
set
and
synchronized
at
first
time
between
platforms
would
wishes
are
the
same
and
what
hitches
are
different
and
probably
try
to
identify
a
time
where
some
features
can
be
ported
to
different
platforms.
It
is
some
idea,
probably
for
some
different
cases.
A
D
Yes,
it's
a
probably
a
good
example
where
one
feature
was
integrated
to
illumise,
but
not
integrated
to
some
other
sport
platforms,
linux
and
freebsd,
the
same
issue
with
dream
support,
probably
and
some
and
other
differences
between
linux,
illumise
and
3ds
D,
because
Linux
have
some
another
implementation
of
some
additional
features.
What
are
not
available
on
illumise
and
probably
in
one
point.
We
need
to
try
to
identify
a
full
list
of
features
both
are
available
on
all
platforms
and
identify
additions.
A
So
I
think
that
the
end
goal
that
you're
describing
is
kind
of
the
same
angle
that
we're
all
talking
about
now
and
it's
something
you're
suggesting
that
we
have
a
more
detailed
document
than
feature
matrix,
especially
to
attract
that
were
key.
You
know
in
more
detail
than
just
like
device
removal
as
one
thing,
but
to
track.
D
D
Disappointed
it
is
probably
we
need
provide
a
tag
or
label
would
feature
available
on
some
platform,
for
example,
if
device
removal
available
for
the
rumors,
we
need
to
identify
this
change
said
and
market
as
tag
or
label,
and
it
will
be
probably
start
point
for
next
to
platform
and
other
buttons
where
they
can
take.
A
look
commits
start
point
for
ports
of
thesis
because,
time
to
time
it
probably
hardly
identify.
Where
is
the
start?
Point
for
sound
dishes
can
be
depend
on
some
other
stitches.
Yes,
it
sounds
like.
A
The
problem
that
you're
trying
to
solve
there
is
is
like,
if
I'm
trying
to
port
device
removal,
for
example-
and
there
were
you-
know-
20
commits
that
were
part
of
device,
removal
and
illumos
and
I
need
to
find
all
20
of
those.
It's
like
hard
to
fight
to.
Finally,
okay,
where
do
I
start
with
this
and
then
how?
What
are
the
all?
The
other
commits
that
I
need,
so
I
think
the
question
of
how
to
do
that.
It
is
like.
Where
do
those
tags
live
like?
What
is
this
tagging
thing?
A
Look
like
I
think
that
probably
the
simplest
way
to
do
it
would
be
to
say
that
when
we,
when
we
do
commits
part
of
the
commit
message
should
include
like
a
line
that
says.
Basically,
this
commit
is
a
follow-on
to
this
previous
command
so
like
this
is
I'm
I'm
enhancing
device
removal,
so
I
would
add
some
tag
that
says
you
know
relates
to
or
depends
on
or
something
like
that.
That
says
it
depends
on
this
earlier
commit,
and
then
that
would
that
you
basically
build
like
this
dependency
graph
logical
dependencies
between
the
different
commits.
F
That's
a
that's.
A
good
question
have
like
the
way
I've
been
seeing
it
so
far.
Is
that
it's
more
of
the
latter
we're
just
a
loosely
organized
coordinated
ish
group
of
implementations
that
all
seem
to
actually
govern
themselves
relatively
actually
quite
differently.
So
if
we're
actually
supposed
to
be
one
big
project,
as
opposed
to
just
in
a
confederation
of
smaller
projects,
then
maybe
we
need
to
think
about
how
we're
organized
to
reflect
that
better.
I
think.
E
G
Think
there's
a
fundamental
impedance
mismatch
in
development
philosophy
between
illumos
and
FreeBSD
and
Linux.
You
know
the
ZFS
on
Linux
port
got
six
commits
just
in
the
last
couple
hours.
You
know
their
velocity
is
a
lot
higher
than
FreeBSD
Zora,
Loomis's
and
I.
Think
any
attempts
to
rein
that
velocity
in
are
gonna
fail.
G
Yeah
I,
don't
think
it's
possible
to
get
an
integrated,
FreeBSD
and
Lumos
in
zfo
and
Linux
port,
because
Linux
is
just
gonna,
go
cool
story,
bro
we
we
did
some
stuff,
take
it
or
leave
it.
You
know,
and
and
that's
just
how
they
work.
It's
not
a
bad
thing
or
a
good
thing.
It's
just
fundamentally
different
I
mean.
A
I
jump
in
here
and
give
some
opinions
on
this
too,
and
I
apologize
for
interrupting,
we'll
get
live
run.
You
know,
say
their
opinions
on
it
too.
So
let
me
first
just
get
back
to
Shawn's
original
question
about
like.
Are
we
a
bunch
of
related
projects
or
are
we
one
project?
I?
Think
that
I
think
that
is
a
spectrum
right?
It's
not
I,
don't
think
that
we're
ever
going
to
be
100%
of
one
or
the
other
I
think
that
my
goal
for
the
group
is
that
we
try
to
move
towards
being
one
project.
A
You
know
we're
all
working
with
very
similar
code
bases,
basically
identical
concepts
and
I
think
we
benefit
a
lot
from
coordinating
our
work
and
from
making
sure
that,
like
our
work
is
available
to
everyone,
who's
using
ZFS
I
think
that
folks
don't
want
to
see
an
ideological
separation
of
ZFS
on
Linux
vs.
ZFS
on
Lumos
versus
the
FSM,
FreeBSD
and
I.
Think
that
applies
both
to
developers
and
even
more
so,
to
end
users
who
want
to
be
able
to
you
know,
bring
their
pools
and
their
skill
sets
in
their.
A
You
know
their
admin
skills
from
one
platform
to
the
other
right
like
if
I
find
out
how
to
administer
and
use
ZFS
really
well
on
FreeBSD
I
want
to
be
able
to
go,
find
a
job
where
I'm,
using
and
administering
ZFS
on
illumos
or
Linux
as
well.
So
I
think
that
there's
a
there's,
definitely
a
big
incentive
on
thinking
on
that
goal
of
one
one
project.
Now
the
reality
is
like.
A
There
are
three
different
code
base,
three
different
major
code
bases
and
and
even
more
when
we
get
to
in
talking
about
Mac,
OS
and
and
Windows,
and
so
that
are
part
of
three
different
projects
that
are,
you
know,
managed
separately
with
different
politics
and
different
velocities
all
right.
So
you
know
kind
of
getting
to
the
last
point
that
was
made
about
the
impedance
mismatch.
I
think
that
there
I
I,
I,
agree
and
acknowledge
that,
like
the
rate
of
change
of
commits,
is,
is
different
on
the
different
platforms.
A
But
I
don't
I
disagree
with
the
assessment
that
ZFS
on
Linux
is
kind
of
doing
its
own
thing,
with
our
regard,
for
what
is
good
for
other
platforms,
I
that
the
difficulty
is
that,
like
there's
a
lot
of
changes,
there's
a
lot
of
change
requests
and-
and
there
is
a
lot
of
velocity
there.
So
in
order
for
you
know,
there's
a
fast
linux
projects
you
take
into
account.
You
know
what's
good
for
other
platforms,
we
need
to
know
what's
good
for
them.
A
We
need
people
from
those
bathrooms
to
show
up
and
say,
like
hey,
like
need
to
slow
down
in
this
review
like
it's
not
ready
or
like
it
doesn't
work.
Well,
it's
not
going
to
work
well
on
freebsd,
so
we
need
to
rethink
it
or
to
educate
the
folks
who
are
kind
of
in
charge
of
the
z
vessel
in
this
project.
Like
me
and
Brian
and
other
new
prominent
folks,
you
know
to
educate
us
that
you
know
hey.
This
type
of
change
doesn't
work.
A
Well,
you
need
to
like
this
term
change
doesn't
work
well
on
and
Lumos.
You
need
to
check
with
us
or
like
rethink
it,
so
that
we
can
alert
folks
from
those
platforms
about
those
changes
you
know
before
they
go
in
so
I
think
that
there's
work
that
needs
to
be
done,
but
I
think
that,
like
ZFS
on
Linux
does
not
want
to
be
the
wild
wild
west.
Where
anything
goes,
and
you
know
like
you
can
take
whatever
broken
software
arrives
there
like.
That
is
absolutely
not
the
goal.
The
goal
is
to
be.
E
A
You
know,
like
things
are
not
perfect,
but
I
think
that
we
all
kind
of
we're
all
coming
from
a
similar
goal
and
you
need
to
help
each
other
to
achieve
that
goal
now.
I
know
that's
a
lot
of
like
mom
and
apple
pie,
kind
of
talks,
so
I'll
cede
the
floor
to
other
folks
who
want
to
offer
their.
You
know
perhaps
counter
your
counter
points
or
opinions.
I
mean.
H
Matt,
it's
honestly
kind
of
refreshing
hearing
that
coming
from
you,
I
actually
didn't
know
that
you
were
heading
up
part
of
the
CFS
on
links.
Project
I
mean
in
my
experience.
In
the
past,
it
always
seemed
like
see
like
zo
L
was
kind
of
lagging
behind
other
implementations.
So
it's
good
to
see
a
lot
of
rapid
build
on
that
end.
But
I
just
want
say
like
it's.
It's
really
good
to
hear
that
you
don't
want
to
take
the
the
Linux
approach
to
things
and
I
mean
I.
Shouldn't
I
should
know
that.
H
Coming
from
you,
because
I
mean
in
my
experience,
you
know
a
lot
of
stuff
on
Linux
is
very
much.
You
know
secure
everybody
else,
we're
doing
our
own
thing.
We're
gonna
do
as
quickly
as
possible,
and
you
know
the
heck
with
bugs
the
heck
with
stability
heck
with
other
platforms.
So
knowing
that
zo
L
is
kind
of
sticking
to
that
old-school
ethos
of
like,
let's
make
sure
that
things
are
working.
H
Let's
make
sure
stuff
is
shipping
out,
and
it's
stable
that
just
that
concepts
my
mind
at
ease
because
I've
been
real
concerned
over,
like
the
last
I.
Don't
know
about
year,
you
know
seeing
a
lot
of
the
GOL
progress
and
hear
a
lot
of
talk
about.
Let's
make
Co
l
sort
of
the
upstream
source
of
truth
that
had
me
worried
for
a
while.
So
let's,
let's
worry
now,
I
just
want
to
say
that
I,
like.
I
To
jump
out
there
and
say
that
we
absolutely
do
care
a
lot
about
quality
in
vol,
we
set
up
a
lot
of
testing
infrastructure
and
I
think
we
do
bring
that
eat.
Those
of
we
don't
want
to
put
anything
ever
in
the
tree
that
is
buggy
so
trying
to
dispel
that
myth
a
little
bit
from
the
other
port
that
we
do.
E
G
Is
unstable
or
willing
to
commit
broke?
That's
because
I
think
the
code
quality
of
Linux,
especially
recently,
where
recently,
as
last
five
to
ten
years,
it's
pretty
high
the
quality
of
the
stability
of
Linux
I
and
what
my
point
would
be
is
I
think
that
FreeBSD
is
far
more
concerned
with
making
sure
things
work
on
Linux.
Then
Linux
is
concerned
with
making
sure
things
work
on
FreeBSD.
Yes,.
F
F
And
I'm
just
gonna
jump
in
just
a
little
bit,
because
if,
while
I'm
a
little
bit
of
a
newcomer
here,
I've
been
working
with
Brian
and
other
members
of
0l
to
improve
the
stability
and
whatnot
I.
Don't
think
it's
quite
a
fair
characterization
to
say
that,
like
we're,
just
trying
to
like
as
a
whole,
with
the
limits
platforms
that
we're
we're
changing
things
for
the
sake
of
change,
I
think
it's
more
about.
F
We
we're
adapting
to
a
larger
variety
of
different
problems
and
solutions
that
we
have
to
come
up
with,
and
things
just
get
way
more
complicated.
We
have
to
deal
with
it
a
lot
more
quickly
because
of
the
just
the
broader
base
of
people
using
it.
That
doesn't
mean
that
we
don't
care
about,
say,
FreeBSD
or
Lumos,
or
you
know
any
other
operating
system
platform
that
wants
to
use
ZFS.
But
you
know
from
our
perspective,
at
least
with
the
from
you
know,
my
work
with
the
zo
L
test
and
test
infrastructure.
F
F
Let's
test
to
see
what
this
feature
makes
sense
on
all
the
different
OSS,
but
for
now
we
don't
have
that
so
I
mean
it's
not
that
we're
trying
to
go
fat
faster
than
everyone
else
or
you
know,
break
all
the
things
or
anything
like
that
and
I
have
some
suspicions
of
where
that
particular
concern
is
coming
from.
But
you
know
that's
for
a
different
point,
but
I
think
we're
trying
really
hard
to
be
able
to
address
every
one
and
move
things
forward
faster,
while
maintaining
a
high
level
of
quality
across
the
board.
F
I
mean
we're
simultaneously
handling
both
the
Linux
kernel,
commit
and
style
standards,
as
well
as
the
illumise
ones,
and
that's
a
hard
thing
to
by
itself
that
particular
bit
is
difficult
enough
to
satisfy
there's
a
whole
lot
of
things.
You
know
that
goes
into
the
ZFS
testing
and
quality
assurance
that
we
try
to
do
on
every
commit
that
goes
not
even
into
the
code
base
but
being
proposed
into
the
code
base.
So
I
think
that
it's
unfair
to
consider
that
it
is
that
we're
just
screwing
up
everyone,
I.
C
A
C
C
G
Let
me
close
the
loop
on
that
since
I
brought
this
up.
I,
don't
I,
don't
think
that
there's
a
problem
with
the
different
indifference
in
development
pathologies
at
all,
I
think
ignoring
that
that
problem
exists
or
that
that
impedance
mismatch
exists.
I
shouldn't
even
call
it.
A
problem
is
bound
to
cause
problems
in
of
itself.
G
I
think
that
to
maintain
compatibility
between
the
platforms,
you
should
focus
on
features
because
I
think
things
aren't
going
to
sit
on
the
ZFS
on
Linux
to-do
list
for
three
years,
while
people
contemplate
how
they,
how
they're
gonna
do
that
or
we
should
do
that
someday
or
that
sure
would
be
nice
to
add.
There's
it's
just
gonna
happen
and.
G
Sorry,
a
neil
is
that
was
that
your
point,
your
point
they're
going
to
try
as
hard
as
possible
to
make
sure
there's
compatibility
and
they're
not
going
out
of
their
way
to
break
things
and
going
out
of
their
way
to
change
things.
Just
for
the
sake
of
changing
it,
I,
don't
I,
don't
think
anybody
is
interested
in
doing
that,
but
at
the
end
of
the
day,
they're,
not
illumise,
experts
right.
J
D
Is
it's
free?
Yes,
because
we
have
had
a
Loomis
Co
the
base
first,
and
it
was
ported
to
some
others
platform.
It
was
why
illumise
process
in
first
probably
and
the
issue
for
others
I
think
if
we
can
change
integration
process,
it
will
be
much
more
better
for
other
platforms
and
probably
for
some
other
platforms.
We
have
to
add
some
platform,
specific
definition
for
enable
or
disable
some
teacher
sites
between
different
platforms.
Yeah.
F
H
That
would
be,
and
that
would
be
an
ideal
situation.
You
know
having
you
know,
splits
or
sort
of
splitting
things
out.
So
there's
a
single
universal
OS
agnostic.
You
know
giant
GFI,
you
know
open
ZFS
project
and
then
you
know
just
nudging
things
individually,
I
mean
I,
obviously
I'm,
not
a
ZFS
developer.
The
I
just
I
like
ZFS
and
I've
written
some
crappy
tools
around
it.
H
But
you
know
I
mean
I'm,
not
a
ZFS
developer,
so
I
keep
meaning
to
dig
into
the
code
base
and
maybe
I'm
already
describing
a
large
portion
of
what's
already
occurred,
but
I
mean
just
from
you
know
a
complete
outsider's
perspective.
As
you
know,
some
who
hasn't
touched
the
codebase
yet
keep
just
keeps
meaning
to
you
know
having
like
a
single
Universal
source
of
truth
and
then
I
guess
like
shim
layers
to
adjust
to
you,
know
individual
behavior
on
individual
operating
systems.
May
you
know
if
that's
not
what
we're
already
doing?
H
It
may
be
worth
considering
that,
as
you
know,
something
to
look
at
sort
of
an
end
goal.
So
there
isn't
a
concern
about
you
know.
Zfs
on
Linux
is
like
doing
all
this
stuff
and
everybody's
getting
left
behind,
or
you
know,
ZFS
on
freebsd
isn't
moving
quickly
enough
or
does
anyone
even
still
run
mmo's
I
love,
Solaris
I
level
in
motion.
A
Right,
just
jump
in
and
say
like
that
is
that
would
be
I
agree.
That
would
be
an
ideal
state
of
the
world.
It's
it's
just
we're
pretty
far
off
from
being
able
to
achieve
that
technically
and
I
think
you
know
we
were
talking
about
undertaking
some
pretty
big
amounts
of
work
here.
Just
to
you
know,
get
again
all
the
source
code
like
more
aligned
than
it
is
now.
A
So
you
know,
if
that's
if
folks
feel
like
we
should
be
taking
on
that
degree
of
work
like
I'm
all
for
it,
but
I
also
want
to
keep
the
things
I
wanted
to
keep
us
down
to
earth
in
terms
of
what's
actually
achievable
and
I.
Think
having
like
a
1:1
repo,
that's
the
source
of
truth
that
everybody
else
is
pulling
from
is
I
like
that
would
be
nice.
I!
Think
that
we
should.
We
should
try
to
get
in
that
direction.
We
should
try
to
get
our
source
code
to
be
more
similar
than
it
is
now.
A
We
should
try
to
get
our
integration
processes
so
that
everyone
is
involved
in
things
getting
in
in
you're
approving
stuff
to
be
integrated,
and
you
know,
maybe
once
we
get
closer
to
that,
then
we
could
think
about
having
you
know,
a
repo,
that's
actually
independently
buildable
and
testable,
and
you
can
run
it
all
on
user
land
on
any
platform,
but
I
think
that's
a
whole
other
project.
That
would
be
very
conservative
will
to
undertake.
Well.
H
H
Conservative,
in
my
estimates,
but
I
mean
you
know,
I'm
saying
more
is
like
sort
of
a
guiding
principle.
You
know
as
something
to
move
towards
over.
You
know
slowly
over
time,
not
as
like
a
primary
goal
for
like
okay.
We
want
to
have
this
by
you
know.
You
know
this
time.
You
know
five
years
from
now
as
a
hundred
percent
definite,
but
it's
you
know
keeping
it
in
mind
as
we
develop
and
as
we
move
in
that
direction
towards
a
unified
code,
I
think
is
more
that's
more.
E
I
think
we
all
agree
on
on
like
where
we
want
to
be,
but
I
think
the
question
is:
how
do
we
get
there
and
I
think
so
far?
The
big,
the
two
big
proposals
that
we've
had
so
far
are
either
move
features
over
kind
of
one
at
a
time,
and
we
have
you
know
each
on
each
system.
There
is
somebody
responsible
for
each
feature
and
the
other
one
is
again
trying
to
like,
say:
okay,
here's,
the
current
difference
between
Lumos
and
Linux,
or
FreeBSD
and
aloo,
most
or
whatever,
and
trying
to
resolve
those
differences.
A
C
Briefly,
I
think
for
all
the
think.
There
are
a
number
of
reasons
why
it's
unlikely
that
we're
going
to
end
up
with
a
single
sole
space,
I
think
anytime,
soon,
possibly
ever
what
I
think
we're
more
most
interested
in
in
the
illumos
wall,
because
we're
probably
always
going
to
be
a
little
bit
of
I.
Think
you
know
we're
interested
in
a
design
review
basically
like
if
the,
if
we're
gonna,
add
flags
to
the
Deadpool
command,
to
set
fsq
on
things
like
that
use.
C
A
visible
surface
area
like
by
way
of
example,
I
think
that,
like
Zeb,
will
create
on
Linux,
can
take
an
a
shift
option,
but
I
think
that
it
probably
would
have
been
better,
at
least
for
us,
for
it
to
be
able
to
take
like
a
forced
block
size
option
instead,
and
we
would
because
the
a
shift
would
then
remain
like
an
implementation
detail.
That's
the
stuff.
C
If
there
are
other
venues
that
we
should
be
participating
in
to
try
and
get
earlier
visibility
into
big,
particularly
user,
visible
interface
sort
of
changes,
then
we
would
like
to
do
that
too,
and
I
think
that
that's
the
that's
the
area
where
we're
going
to
be
able
to
most
cheaply
and
most
quickly
get
involved
in
that
process
of
decision
making,
rather
than
whereas
right
now,
obviously
we're
quite
far
behind
on
sticking
up.
So
it's
harder
for
us
to
like
take
each
patch
tested.
D
Some
flags
some
tickets
between
different
platforms.
If
we
have
no
some
agreements
about
flags,
one
platform
implement
achieved
and
as
a
platform
vice
blocksize
for
something
else,
we
need
some
agreements
between
platforms
and
probably
try
to
switch
to
use
some
No,
understandable
and
more
feature
flights
and
comment
flags
if
needed.
When
you
try
to
specify
the
flights
and
try
to
discuss
agreements
between
platforms
and
implements
yeah.
A
So
I
think
all
the
stuff
that
we're
talking
about
here
is
is
not
really
platform.
Specific
and
I.
Think
that
I
think
that
if
I
could
kind
of
up
level
it
a
little
bit,
I
would
say
we
need
to
make
sure
that
we
have
the
best
people
available.
Reviewing
changes
to
ZFS
on
on
regards
to
the
platform
that
those
changes
are
originally
being
made
on.
A
So,
like
you
know,
Josh
I
happen
to
agree
with
you
of
your
views
of
whether
it
should
have
been
called
a
shift
but
like,
for
example,
it
would
have
been
great
if
Josh
knew
about
this
change.
To
add
this
a
shift
flag
when
it
was
being
made
and
could
could
have,
you
know,
offered
his
opinion
on
it
at
the
time
and
the
relevant
folks
would
have
taken
that
into
account.
And
you
know
we
all
could
have
had
a
discussion
about
it
and
come
to
a
conclusion.
A
I,
don't
think
that
I
I
think
that
it
isn't
like
Oh.
Is
there
a
Loomis
way
or
the
CFS
olynyk's
way?
It's
just
a
matter
of
like
we're
all
using
the
CFS
and
we
all
want
CFS
to
work
like
the
best
way
possible,
and
we
want
to
make
sure
that
our
opinion
of
the
best
way
is
heard
and
considered
by
everybody.
At
the
time.
The
change
is
being
made
because.
C
We're
gonna
I
mean
we're
gonna,
take
the
a
shift
option
basically
like,
and
it's
fine
it's
it's
just
that
so
that,
like
we
do
absolutely
want
to
be
consistent
with
all
of
the
implementations,
and
for
that
to
be
easier
to
achieve.
We
would
just
like
to
make
sure
that
it'll
make
sense
for
us
to,
but
yeah
yeah.
A
C
A
Get
the
last
well
and
that
Brian
would
get
the
last
word
on
this
overall
I'd
like
to
kind
of
hold
off
for
the
discussion
on
this,
so
that
we
have
a
little
bit
of
time
for
more
specific
things,
one
of
which
I
think
will
be
pretty
relevant
to
this
I
mean
kind
of
let
Brian
have
a
couple
words
about
kind
of
what
your
thoughts
are,
since
you
are
kind
of
the
de
facto
leader
of
ZFS
on
Linux
and
I.
Think
folks
would
like
to
hear
from
you
on
a
bunch
of
topics
here.
Yeah.
I
So
I
agree
with
most
of
what's
been
said.
Actually
I.
Think
I
completely
agree
with
where
we
want
to
be
would
be
really
nice
to
have
a
platform,
but
it's
a
long
ways
off.
As
for
the
features
that
have
been
talked
about
and
reviewed,
yeah
we've
merged
a
lot
of
things
for
Linux,
add
new
features
that
we
probably
should
have
gotten
more
input
from.
I
But,
conversely,
we've
pulled
a
lot
of
things
from
alumina
or
FreeBSD
that
we
look
at
and
say:
oh
I
wish
you
hadn't
done
it
that
way,
so
I
completely
sympathize
with
the
comments
about
you
know
getting
people
from
all
the
platforms
to
review
any
changes.
I
think
that's
really
important.
Going
forward,
I'd
like
to
also
throw
out
there
that
we
were
behind
for
a
long
time
on
Linux
between
all
the
other
platforms
and
we
found
that
a
good
way
to
catch
up
while
painful
was
systematically
going
through
all
the
commits.
I
It
really
does
take
a
lot
of
work
and
effort,
but
I
mean
we
found
that
everyone
we
pulled
through
their
platforms.
We
had
to
make
platform
specific
changes
to
where
I
could
look
at
it.
We'd
evaluate
in
the
context
of
Linux
and
get
it
merged,
so
it
was
systematic
and
it
was
slow,
but
we
did
get
there
eventually,
I'm,
not
sure
pulling
things
in
with
features
is
gonna
work
out
too
well.
Well.
Does
it
get
my
quick
thought.
D
A
Yeah
I
mean
I
think
that
that
kind
of
goes
to
what
we've
been
saying
that
you
know
changes
that
affect
these
are
interface
need
to
be
reviewed
by
you
know.
Everyone
who
has
you
know
informed
input
and
that's
going
to
come
from
all
different
platforms,
so
I
think
raising
the
visibility.
You
I
think
it's
a
great
idea
that
we
should
raise
the
visibility
of
changes
that
would
impact
the
user
interface
and
make
sure
that
those
are
known
and
reviewed
by
folks
on
each
platform.
A
So
in
terms
of
how
to
actually
do
that,
you
know
maybe
this
the
simplest
way
would
be
to
say
you
know
hey
when
we're
adding
a
new
flag
or
changing
the
user
interface.
You
know
post
a
message
to
the
open,
ZFS
developer.
Mailing
list
I
mean
think
that
could
be
part
of
the
review
process
like
when
somebody
puts
ZFS
online
Explorer
request.
You
know
we
should
say:
hey
you're,
changing
the
user
interface,
let's
make
sure
they're
to
get
this
reviewed
by
the
broader,
open,
ZFS
communities.
C
A
Yeah
so
I
think
I
mean
I'll,
go
ahead
and
make
that
proposal
and
say
hey,
let's,
let's
try
and
do
that
I'll
send
out.
You
know
some
messages
to
the
mailing
list,
kind
of
propose
things
more
formally.
Since
you
know
this
is
this
is
this
is
not
supposed
to
be
a
meeting
where
we
necessarily
make
decisions
for
all
of
the
entire
community,
since
not
everyone
is
able
to
attend
this,
but
I.
Think
if
folks,
you
agree,
then
I'll
send
it
out
as
a
proposal
for
how
we
work
going
forwards.
A
It's
a
very
good
question,
I'm
glad
that
we
folks
have
the
opportunity
to
discuss
this.
You
know
we
all
need
to
be
kind
of
on
the
same
page,
with
respect
to
these
high-level
things
in
order
to
I
think
make
make
good
progress
on
the
more
detailed
stuff
and
having
that
shared
context
of
like
you
know,
ZFS
and
Linux
isn't
just
trying
to
be
its
own
thing.
A
You
know
that's
important
for
be
able
to
work
well
together,
and
you
know
the
the
point
of
the
open
ZFS
organization
and
in
this
meeting
being
part
of
it,
is
to
get
folks
on
the
same
page
and
to
bring
together
the
folks
who
know
about
ZFS
and
make
sure
they
were
all
like
making
ZFS
the
best
it
can
be
on
every
platform.
So
that's
really
the
point
of
the
organization,
so
I'd
like
to
change
gears
a
little
bit
and
look
at
some
of
the
agenda
items
from
the
document.
A
A
My
I
think
there's
kind
of
a
broad
range
from
kind
of
most
conservative
to
most
radical.
The
the
most
conservative
approach
that
I
think
probably
most
folks
could
agree
is
a
good
idea
would
be
to
have
like
option
when
you
use
equal,
create
that's
like
zero,
create
compact
or
compatibility
equals,
and
then
you
could
fill
in
like
FreeBSD,
10,
comma
gol,
o
dot,
7.3,
comma
illumise,
whatever
I
see,
heads
are
being
shaking
the
wrong
way,
we'll
get
to
that.
A
I
think
that
that
is
I
think
that's
an
incremental
approach
and
it's
pretty
specific
about
what
it
lets
you
do.
Kind
of
the
other
end
of
the
spectrum,
which
is
what
which
was
proposing
was
basically
like
when
you
create
a
pool
by
default.
No
features
should
be
enabled.
Therefore
you
know
you
have
maximum
compatibility,
and
you
know
it's
up
to
everyone
to
enable
features,
as
you
know,
as
they
want
I
I'm,
not
a
big
fan
of
that,
because
it
means
that
folks
will
be
using
it.
A
That's
a
great
question:
I
think
that
how
we,
how
we
identify
the
versions
is
is,
is
a
big
open
question
and
I
think
what
the
defaults
are
is
also
an
open
question,
so
you
could
imagine
that
you
know.
Maybe
maybe
the
default
should
continue
to
be.
All
features
are
enabled.
Maybe
the
defect
rate
should
be.
You
know,
features
that
are
available
on
all
platforms
when
you
know
when
this
release
was
made
should
be
enabled.
Maybe
it's
features
that
have
been
on
all
platforms
for
one
year
should
be
enabled
I.
B
I
was
shaking
my
head
so
rapidly
listing
every
operating
system.
Inversion
is
a
horrible,
horrible,
horrible,
non-scalable
idea.
If
we're
going
to
do
that
sort
of
thing,
I
would
instead
recommend
you
come
up
with
years
and
quarters
in
2018
q2,
all
the
ones
we
care
about
head
these
features
you
can
enable
those
that
require
some
active
interaction
with
all
the
players
to
be
able
to
determine
what
those
features
were
for
those
time
stands
you're
effectively
describing.
B
A
A
Think
I
think
treating
that
as
kind
of
a
minimum
of
what
we
would
do
it
like.
That
sounds
great
to
me
and
if
having
everything
a
release
being
listed
is
too
much
then
you
know
I
think
that's
reasonable
as
well.
At.
I
I
F
Yeah,
so
we
in
the
Linux
side
it's
already
operating
this
way.
The
only
complication
is
that
is
really
some
of
the
down
street.
The
the
downstream
situation
for
zo
l
makes
things
a
little
tricky,
but
from
a
perspective
of
saying
like
these,
are
the
defaults
that
you
expect
when
you're
talking
about
what
we've
released
in
zo
l,
then
I
think
that's
workable,
because
as
long
as
we
don't
consider
as
long
as
we're
not
trying
to
incorporate
downstream
information,
we
can.
It
becomes
a
relatively
simple
matrix
when.
F
C
A
F
Yeah
so
like
most
prominently
with
the
bun
to
like
just
just
from
you
know
from
my
personal
experience
of
you
know,
bashing
my
head
into
the
ground
with
it
is
that
the
kernel
and
user
space
utilities
are
out
of
sync.
So
you
cannot
expect
that
the
feature
set
will
actually
exactly
match
between
use
from
the
user
space
tools
that
are
shipped
versus
the
kernel
space
code.
That's
in
the
current
in
bundled
into
their
kernel
images.
F
But
well
it's
it's
not
out
of
sync
to
the
set
extent
that
you're
not
that
you'll
you'll
really
notice
it
like
it's
not
like
they're
bumping
like
a
feature
set
or
two
or
something
like
a
feature
version
but
like,
for
example,
the
kernel.
Might
the
kernel
tree
might
be
shipping
a
0
7,
the
so
like,
let's
say,
for
example,
0
7
6
was
what
shipped
in
in
the
in
the
user
space
utilities
and
that's
what
went
out
in
GA
in
the
kernel
tree
for
that
release.
F
But
if
it
was
a
long-term
release
like
going
forward,
the
kernel
software
will
move
forward,
maybe
a
little
bit
occasionally
maybe
they'll
be
cherry,
picks
or
back
ports
or
whatnot,
but
the
user
space
utilities
never
get
updated,
for
example,
so
that
gets
that
gets
a
little
tricky
when
it
comes
to
figuring
out,
what's
actually
supported
and
activated.
So.
A
In
the
bucket
that
we
have
left
can
I
ask
I'm
sorry
I
interrupted
you
there
today
can
I
ask
folks
on
the
more
controversial
issue
of
what
the
default
should
be.
When
you
create
a
pool.
Do
you
think
that
the
default
should
continue
to
be
everything
enabled
should
it
be?
Some
things
are
enabled
based
on
what's
available
at
this
date,
and
that
kind
of
changes
over
time
or
or
nothing
is
enabled
or
something
in
between
so.
E
I
think
that
the
primary
thing
that
both
like
the
users
or
mostly
the
fuses,
are
gonna
be
concerned
with
is,
can
I
get.
You
know
you
you're
either
in
the
camp.
Oh
I
want
to
be
able
to
move
this
to
another
platform
or
not,
and
so,
if
we
have
like
a
compatibility
mode,
I
think
all
that
they
really
care
about.
It's,
not
necessarily
what
version
they're
compatible
to
but
I
think
it's
can
we
get
a
version
on
the
Lumos
or
FreeBSD
or
Linux
or
whatever
it
may
be.
That's
compatible
with
that
version.
I
E
Lots
of
our
problems
went
away,
so
I
think
doing
features
by
default
is
probably
what
we
want
to
do
and
for
the
people
who
are
more
aware
and
of
the
fact
that
they
may
be
moving
I
think
we
should
make
it
a
flag,
that's
available
to
them.
For
that
and
again,
I
think
that
we
we
don't
need
that
I,
don't
think
we
need
to
be
listing.
K
G
Three
modes:
full
compatible.
You
know
full
features
as
the
default
no
features
as
sort
of
a
I
know
what
I'm
doing
and
I'm
gonna
selectively
enable
and
any
least
common
denominator
feature
set.
You
know
like
a
compatibility
mode,
it's
just
at
the
time
of
the
release.
It
enables
all
the
flags
that
are
that,
were
you
know,
available
across
all
of
the
tier
one
releases
right.
E
C
D
D
C
D
Think
we
can
make
a
name
of
features
between
platforms.
For
example,
we
can
create
universal
compatibility
name
and
the
different
list
of
features.
What
can
be
used
between
quadrant,
for
example,
I,
want
to
create
a
pool.
This
compatibility
version
and
teacher
said,
while
and
I
can
import
and
export
this
pool
between
the
classrooms,
the
Linux
FreeBSD
and
the
Lewis
I'll.
F
So
forth,
I
don't
quite
know
what
you
said:
Igor
sorry,
I
kind
of
missed
it,
but
at
least
from
my
perspective,
I'm
just
gonna
say
what
I
would
hope
for
is
the
most
optimistic
for
new
stuff
and
the
most
pessimistic
for
pool
upgrades,
and
so
that
means
that
if
there
wasn't
a
flag
turned
on
before
it
should
not
be
on
going
forward.
When
you
upgrade
when
you're
making
brand
new
pools
from
scratch,
I
would
say:
let's
flip,
on
all
the
features,
unless
somebody
sets
a
mode
that
says
otherwise.
D
He
says
we
can
upgrade
between
known
teacher
sets,
for
example,
if
I
won't
upgrade
a
pool
from
future
named
Fisher
one.
These
are
two
teachers
three
and
this
Fisher
name
will
be
available
on
all
platforms
and
I
can
upgrade
my
pool
on
the
known
teacher
name.
If
I
want
to
use
this
pool
on
different
platforms,
this
idea,
we
need
a
specified
universal
name
with
the
list
of
dishes.
F
F
C
F
F
A
B
I
A
So
folks,
time,
where
any
two
minutes
over
I
think
this
is
a
great
discussion
both
about
kind
of
the
meta
stuff
of
what
is
the
project?
What
are
our
goals
it,
and
it
sounds
like
one
of
the
big
conclusions
out
of
that
is
that
the
most
and
FreeBSD
you
want
to
work
by
kind
of
going
through
the
Linux
commits
one
by
one
and
pulling
them
over
in
roughly
chronological
order,
rather
than
project
based,
and
then
the
discussion
about
the
cross
platform
pool
compatibility,
I
think
I.
G
A
K
Two
quick
things
Igor
asked
about
moving
this
meeting
to
11:00
a.m.
doesn't
mean
that
you're
good,
we'll
probably
never
doing
this,
but
maybe
that's
almost
also
at
least
Ruth.
Are
people
be
able
you
can?
If
you
click
under
more
on
zoom,
you
can
do
a
thumbs
up
or
a
thumbs
down,
and
then
also
next
regularly
scheduled
meeting
is
on
January
1st
and
about
the
rest
of
you
well
plan
to
be
dialing
in
on
January
1st,
so
I'm
going
to
move
it
to
January
8th.