►
From YouTube: Second March 2021 OpenZFS Leadership Meeting
Description
At this month's meeting we discussed: version numbering scheme; OpenZFS conference; patches from DilOS
meeting notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit
A
B
Sure
this
is
something
that
came
up
a
few
months
ago.
I
would
say,
and
we
we're
going
to
talk
about
it,
but
basically
nailing
down
what
the
version
numbers
mean
in
open
zfs,
and
I
would
say
what
I'm
going
to
propose
is
something
that,
like
we've,
basically
been
doing
this
whole
time.
So
it's
not
really
a
change,
but
basically
we
just
use
the
major
minor
patch
scheme
that
is
pretty
commonly
used
everywhere.
B
The
major
number
would
basically
be
incremented
at
our
discretion.
I
would
say
when
a
noteworthy
feature
comes
into
open,
vfs
or
we
have
some
other
reason
to
bump
the
major
number.
We
could
do
that,
otherwise
we
would
just
bump
the
minor
number
for
major
new
features
or
new
properties.
New
feature
flags,
new
command
line
options.
That
kind
of
thing.
So
that's
consistent
with
what
we
said
the
date
where
we
put
out
a
2.1
release,
which
would
include
some
new
features,
so
that
would
be
d
raid
and
the
pool
compatibility
stuff.
B
B
We
try
to
minimize
the
disruption
there,
so
we
might
bump
it
for
kernel
compatibility,
patches
and
whatnot,
but
I
think
that's
all
pretty
consistent
with
what
we've
done
to
date
with
all
the
open
zfs
releases
before
so
that's
the
kind
of
the
the
high
level
view
of
what
the
digits
would
mean,
and
I
think
it's
pretty
normal.
I
can
put
something
up
on
the
on
the
website
or
in
an
issue
or
somewhere,
and
we
can
comment
on
it
and
refine
a
little
bit
more,
but
that's
the
general
idea.
A
Just
to
kind
of
map
that,
on
to
what
we've
been
doing
you
know
in
the
odot,
whatever
scheme
so
basically
like
the
roughly
annual
sort
of
big
releases,
would
be
either
either
a
major
or
minor
bump,
depending
on
kind
of
our
discretion
of
like.
Is
this
really
no
super
noteworthy
year
or
is
it
just
a
kind
of
regular
everyday
year?
And
then
the
patch
releases
would
be
the
releases
that
go
out
like
every
couple
of
months
with,
like
you
said,
you
know,
bug
fixes
and
support
for
new
kernel
versions.
C
B
That
would
be
the
idea
I
mean
in
my
thinking
that
makes
sense,
because
the
major
version,
the
efficient,
always
be
compatible
right.
That's
kind
of
the
big
takeaway
from
this
like
like
bumping.
The
major
version
would
indicate
some
kind
of
major
incompatibility
and
that's
not
something
we
ever
really
want
to
do
with
zfs.
So
we.
B
Yeah
like
if
I
were
to
see
a
major
version,
but
I
might
think
that
it
would
be
completely
incompatible.
Oh
no
open,
vfs
3.0
was
competing
compatible
with
2.0
right.
That's
never
going
to
be
the
case
right.
We
never
want
that
to
be
the
case,
so
that's
kind
of
where
some
of
the
thinking
comes
from
there,
but
we
can
bump
it.
If
you
know
we
add
something
new
like
support
for
a
new
platform
or
something
like
that
might
be
noteworthy
enough,
like
we
now
support
windows
all
right,
it's
a
3.0
release,
great.
D
Right,
I
think
that
you
know
when
you
talk
about
incompatibility.
There
is
potentially
on
that
note
a
certain
possibility
of
incompatibility,
if
you
add
support
for
a
new
platform
that
didn't
exist
before
that
version.
That
is
a
form
of
incompatibility
for
that
particular
platform.
They
can't
go
to
2.0.
A
B
Yeah,
so
we're
thinking
about
that
as
well.
I
have
a
what
I
would
suggest
for
that
is
we
do
something
like
a
a
long-term
release
and
then
a
more
rolling,
not
rolling
release.
But
you
know
our
normal
annual
release
is
right,
but
I've
suggested
we
have
a
long-term
branch
and
we
just
designate
one
of
the
tags
it
could
be.
2-0
could
be
2-1,
it
could
be
whatever
as
a
long-term
release
and
we
guarantee
that
we'll
just
apply
bug
fixes
to
that.
B
For
a
year
two
years
three
years
I
will
have
to
pick
a
duration
right,
but
something
reasonable
that
distributions
could
pick
up
and
you
know,
be
able
to
track
and
know
that
they're
going
to
get
important
bug
fixes
for,
but
I
would
say
what
we
would
exclude
from
that
would
be
things
like
new
kernel,
compatibility
changes
or
no
new
major
features
or
anything
like
that
right.
So
you
could
draw
a
line
in
the
sand
about
what's
going
in
here
and
what
isn't?
B
Because
some
of
those
changes
are
really
disruptive
and
anybody's
writing
a
long-term
release
doesn't
doesn't
really
want
that.
Probably
so
I
would
say
that
would
be
the
conservative
roach
and
then
we
can
have
a
normal
release
like
we've
been
doing
to
date.
Basically
that
comes
out
every
you
know,
six
to
12
months,
whatever
something
on
that
cadence,
like
we've,
been
doing
maybe
annually,
and
that
will
just
be
the
latest
release
and
we'll
support
that
until
a
new
one
of
those
comes
out
in
six
to
12
months
or
whatever.
B
A
It
would
be
like
critical
bug
fixes
only
you
know
something.
That's
like
obviously
like
anything
that
could
risk
data
corruption.
You
know
that
would
be
definitely
in
the
long
term
releases,
but
anything
else
would
be
a
question
mark
you
know.
Probably
crashes
would
be
like
yeah.
You
know,
probably
if
it's,
if
it's
like
non-trivial
to
hit
this,
then
or
you
know,
if
it's,
if
it's
not
too
hard
to
hit
this
panic,
then
that's
probably
a
good
candidate
for
for
backboarding
to
a
long-term
release.
A
But
you
know
little
stuff
that
we
have
put
it
pat
into
patch
releases
before
like
yeah,
when
you
pull
a
bunch
of
stuff
into
patch
releases
that
where
it's
like
it's,
it's
basically
zero
risk.
Yeah
we're
cutting
your
release
anyways,
so
we
might
as
well
do
it
like.
You
know
fixing
typos
in
the
man
pages
or
even
like
fixing
like
adding
new
info
to
the
man
pages,
to
make
them
more
clear.
It
makes
sense
because
there's
there's
like
no
risk
but
for
the
long
term
releases
like.
B
B
I
guess
it's
also
worth
mentioning:
we'd
probably
only
have
one
long-term
release
at
a
time
too,
I
guess
we
could
maybe
revisit
that
after
it's
been
a
year
or
two
or
whatever,
but
that
would
be
the
initial
thinking.
Is
it
probably
only
makes
sense
to
have
one
or
maybe
some
window
where
they
overlap
for
a
little
bit
of
time,
but
not
long.
D
A
A
B
E
C
B
A
For
critical
for
fixes
that
are
so
that
are
like,
oh,
like
things
that
we
put
into
patch
releases
where
it's
like,
it's
actually
a
critical
fix,
not
not
a
kernel
compatibility,
not
nice,
to
have
because
we're
here
anyways
but
like
yeah.
We
actually
need
to
get
this
out
asap
because
it's
a
critical
fix,
they're.
C
E
C
B
B
B
A
B
A
B
E
A
A
A
We
need
to
update
that,
but
I
guess
we
basically
decided
like
let's
just
use
the
date
rather
the
the
date
and
they
get
hash
rather
than
the
version
number
but
yeah.
If
we
do
want
to
include
the
version
number,
then
it
makes
sense
to
have
it
be
like
2-0
so
you're
saying
it
would
be
like
2099
or
299
299.99.
E
E
E
E
B
I
think
there's
a
bunch
of
conventions
there
that
we
could
adopt.
I
think
most
of
the
version
managers
these
days
are
pretty
smart
about
doing
things
like
looking
at
the
release.
Fields
too.
So,
like
you
know,
2-2
beta
or
alpha
would
also
be
sorted,
lower
right,
but
they're,
maybe
not
the
best
names
or
that
99
is
fine.
It
just
assumes
we'll
never
get
there,
which
is
probably
true.
Yes
well.
B
C
A
B
B
A
E
A
That
describes
in
that
way
like
we
have
it
like
it's
it's
in
the
source
code.
It
says
that
this
is
our
plan,
and
that
way
you
know
people
can
like
try
to
hold
us
to
it
by
point.
But
you
know
it's
not
just
like
some
document
on
open
dfs.org,
it's
like
actually
in
the
source
code.
That
says
that
we'll
do
this
release
or
you
know
whether
this
criteria
are.
You
know.
B
E
B
A
A
A
A
So
you
know
we'd
love
to
hear
from
you
all
on
what
work
you've
done
either
adding
new
features
improving
the
investor's
performance.
You
know
things
you've
noticed
about
zfs
that
people
might
not
know
like
how
some
how
certain
subsystems
work.
You
know
how
their
performance
impacts
your
workloads,
things
like
that
would
all
be
great
great
topics
for
the
conference
and
yeah.
In
terms
of
the
online
aspect,
we
got
a
lot
of
really
good
feedback
on
the
conference.
How
we
ran
the
conference
last
year.
A
So,
given
that
we
don't
really
know
where
you
know
how
comfortable
people
are
gonna
be
with
traveling
in
terms
of
coronavirus
in
november,
we're
planning
to
have
it
be
remote
only
and
if
things
change
a
lot,
then
maybe
we'll
reevaluate
that
and
have
it
be
like
a
hybrid
but
we'll
definitely
have
it
be.
At
least
you
know
remote
first
kind
of
plan
so
that
people
can
plan
to
attend
or
speak.
Even
if
you
can't
or
don't
think
you
would
want
to
travel
in
november.
A
A
As
you
know,
when
you
use
professional
equipment,
that's
recording
on,
like
I
don't
even
know
what
they
use
like
some
some
high
b
rate
medium
as
opposed
to
whatever
streaming
over
the
internet,
but
it
wasn't
that
hard
to
put
together
like
the
slides
and
and
video
of
people
talking
so
yeah,
we'll
definitely
plan
to
do
that
this
coming
year
and
and
all
years
into
the
future.
I
know
that's
really
valuable.
A
And
I
think
that
we
actually
had
a
lot
more
people
streaming.
It
live
last
year
than
we
typically
have
streaming.
It
live,
like
the
number
of
you
know
in
person,
plus
streaming
was
higher
last
year
than
it
was
in
previous
years.
Probably
just
because,
like
the
idea
of
being
able
to
stream
conferences
was
like
more
on
people's
minds
and
also
maybe
people
may
have
felt
more
included
because
it
wasn't
like
it's
a
live
conference
and
then,
like
ps,
you
can
watch
on
the
stream.
A
A
A
Yeah,
I
think
the
hackathon
would
probably
be
more
difficult,
and
I
think
that
I
think
that
we
lost
like
the
the
first
day
this
the
talks.
I
think
that
doing
the
online
like
we
gave
up
very
little
in
terms
of
the
value
compared
to
having
in
person
but
the
hackathon.
I
think
that
we
do
get
a
lot
more
value
out
of
those
like
kind
of
mixer
type
interactions
where
it's
like.
Oh
like
I'm
just
I'm
here,
I'm
hanging
out,
I'm
like
overhearing.
A
What
the
like
cool
people
are
talking
about
and
then
like
getting
some
ideas
or
trying
to
you
know
see
how
I
can
help
them
out.
It's
a
lot.
You
know
I
felt
like
it
was
a
lot
harder
to
do
that,
and
I
only
saw
like
a
very
few
number
of
people
that
were
like
really
new
to
the
community
like
glomming
on
to
you
know
an
existing
project
by
experienced
members,
it
seemed
like
the
hackathons
last
year
were
much
more
like
you
know.
A
The
people
who
were
on
this
call
were
the
people
who
were
participating
in
the
hackathons
and
ideally
we'd
like
to
use
the
hackathon
to
bring
in
more
people
who
are
new
to
the
community
and
connect
them
up
with
problems
and
people,
and
I
think
that
we
didn't
do
as
good
of
a
job
at
that.
I
think
that's
a
harder,
it's
just
a
harder
job
to
do
without
being
in
person,
and
I'm
sure
we
could
have
done
better,
but
it
it
turned
out
to
not
hit
all
of
the
goals
of
the
hackathon.
A
But
if
you
have
ideas
like
alan
or
other
folks,
if
you
have
ideas
on
how
we
could
make
the
hackathon
like
the
online
hackathon
better,
I
mean
we're.
Gonna
have
an
online
hackathon
this
year.
That's
the
plan
so
yeah.
We
could
definitely
use
ideas
of
how
to
like
change
the
format
or
you
know,
tools
to
use
to
increase
engagement.
Among
you
know
the
kind
of
folks
who
aren't
already
like
that
on
this
on
these
kind
of
calls
and
and
knowing
how
to
you
know,
do
zfs
development
already.
A
Or
maybe
even
people
that
do
know
how
to
do
zfs
development,
but
they're
only
doing
it
like
in
their
company.
Maybe
they
haven't
contributed
anything
upstream
because
they
don't.
You
know
they're,
not
part
of
the
like
open
source
ecosystem
mindset,
and
so
they
aren't
coming
to
these
calls
but
they're.
You
know
they
want
to
learn
about
this
tool
that
they're
using
so
they
come
to
the
conference,
and
then
you
know,
ideally,
we
can
kind
of
rope
them
into.
A
Oh
yeah,
like
you
know,
we're
not
you
don't
have
to
like
think
about
contributing,
like
your
tens
of
thousands
of
lines
of
code
that
you
customize
for
zfs.
Just
you
know,
help
us
solve
this
one
little
thing
and
and
to
draw
them
into
the
community.
I
think
that's.
Those
are
some
of
the
best
kind
of
interactions
at
the
hackathon,
so
figuring
out
how
to
engage
with
folks,
who
you
know
have
a
lot
to
add,
but
are
kind
of
on
the
sidelines.
Right
now
would
be
really
wonderful.
E
And
also
maybe
just
a
couple
more
things
that
aren't
even
necessarily
developer
focused
like
muhammad
from
seagate
last
year,
was
just
benchmarking.
The
mid
io
object,
storage
tool
on
top
of
zfs
and
trying
different
configurations
and
stuff,
and
there
was
just
a
group
of
people
on
a
more
operational
side
of
zfs,
just
yeah
learning
things
and
and
playing
with
it.
And
maybe
I
don't
know
if
we
can
come
up
with
a
couple
more
of
those
types
of
ideas.
E
A
Yeah
we
had
that
last
thing
yeah
last
year
as
well,
but
it
was
just,
I
think,
harder
to
rope
folks
into
it
because
they
weren't
like
oh,
I
came
for
the
talks
in
the
beginning
of
the
day
and
now
I'm
stuck
here
in
this
room
with
all
these
people
who
are
talking
about
doing
hackathons.
So
I
guess
I'll
kind
of
see
what
I
can
do.
A
A
And
I
mean
to
be
fair,
like
for
the
folks
who,
like
checked
out
of
the
hackathon
this
year,
like
I'm,
not
blaming
them.
You
know
like
of
the
folks
who
kind
of
were
the
captive
audience
and
then
and
then
stick
you
know
stuck
around
for
the
hackathon,
like
it's
only
a
small
portion
of
those
folks
that
end
up
like
making
that
that
are
actually
like
roped
into
the
community.
It's
just
that.
A
You
know
those
few
people
can
be
valuable
to
the
community,
even
if,
like
80
of
the
folks
who
were
there
still
just
kind
of
sat
around
and
watched
the
presentations,
you
know
like
that's,
that's
fine.
We
just
gotta
get
those
twenty
percent
of
folks
who
are
who
you
know
happen
to
be
there
and
then
also
happen
to
get
ripped
in
to
somehow
get
roped
in.
Even
though
it's
online.
A
C
C
Yes,
I
have
several
questions.
First,
one
is
announce
I
have
ported
to
dealers,
auto
arc
plus
rebuilt
and
great
fishes,
and
I
have
found
several
issues.
What
I
would
like
to
contribute
and
discuss
try
to
discuss
about
one
issue
with
the
rate
test:
two,
because
we
are
faster
on
dubose
instead
of
on
linux
and
we
are
using
for
testing
for
active
cpu
and
we
are
try
to
up
threads
and
move
faster
and
eat
all
of
ram
and
swap,
and
we
have
a
crashes
with
derail2.
C
If
we
try
to
use
all
available
cpu
on
the
vm,
a
one
fix
for
it,
it
is
try
to
use
two
active
cpu
instead
of
all
available
on
the
vm,
because
we
have
a
snowball
with
threads
and
additional
threads
from
this
tool.
Where
we
try
to
operate
with
new
row
structure
with
abd,
where
we
try
to
allocate
additional
ram
for
some
testing,
I
will
try
to
show
what
we
have
and
how
we
can
fix
it.
C
C
We
have
fixed
abd
related
to
the
us
platform,
because
I
can
see
a
different
implementation
for
linux
and
freebsd,
but
freebsd
version
crashed
on
the
deals
and
I
have
fixed.
It
tried
to
reuse
of
some
additional
ideas
from
linux
platform,
where
you
try
to
store
some
allocation
of
chunks
numbers
and
the
abd
structure
and
try
to
reuse
it
in
next
places.
C
C
And
we
have
found
additional
places
what
I
would
like
to
try
to
contribute
specifically
for
deals
platform
where
we
can
try
to
split
of
some
changes,
and
I
have
a
question
at
this
moment.
I
can
see
some
places
where
we
can
try
to
reuse
linux
code,
but
can
I
add
some
define
as
the
deals
platform
probably
to
all
codes,
because
we
have
some
conflicts.
C
Probably
I
will
try
to
pull
of
some
changes
and
we
can
discuss.
Can
we
move
with
to
separate
between
platforms
or
we
can
try
to
add
some
define
for
additional
platform
to
main
code,
because
one
code
can
be
reused
on
linux
and
bsd,
but
with
our
platform
we
can
see
some
inconsistency
in
several
places,
and
I
would
like
to
upstream
of
our
changes
and
to
one
main
base
of
source
code
and
also
I
try
to
work
on
additional
build
board
where
we
can
try
to
test
our
changes
on
additional
platform
with
all
open,
cfs
changes.
C
A
If
def
dilo
s
yes,
so
I
think
that,
in
my
opinion
at
least,
I
would
want
to
see
that
so
I
guess
first,
we
could
try
to
figure
out
like
how
do
we
remove
these
if
desks
for
all
platforms
and
make
it
more
extensible,
naturally
extensible,
so
that
there's
like
you
know,
instead
of
having,
if
linux
it's
like
in
a
linux
header
file
and
in
a
freebsd
header
file,
and
then
you
can
add
your
own
header
file
in
your
own
repo.
That's
the
dil
os
header
file,
rather
than
having
to
have
the
if-defs.
A
A
So
you
know,
if
that,
if
that's
kind
of
what
you're
working
towards,
then
you
know
like
having
a
big
pr.
That's
like
add
support
for
dilowes
and
we're
going
to
add
you
know,
buildbot
testing
for
us
and
we're
going
to
you
know,
add
some
if
deaths
as
necessary.
I
think
that
would
be
a
great
project
if
we're
not.
A
C
A
Yeah,
I
think
doing
it
a
little
bit
by
bit
is
is
good.
It's
just
that.
I
think
we
should
leave
the
explicit
like
if
def
dillawest
parts
until
the
final
pr,
I
think
that's
what
was
done
like
with
freebsd
and
and
what's
being
done
now
with
mac
os.
It
is
that
you
know
like
now.
You
know:
jorgen
is
like
reorganizing
some
files,
abstracting
some
things
out
without
adding
any
mac
os
specific
code
into
opengfs
yet,
and
then
he
has
like
a
big
pr.
That
will
eventually
add
you.
A
Set
of
mac
os
specific
if
deaths
and
files
you
know
at
the
end
and
that'll
still
be
a
big
pr,
but
you
know
he's
working
to
minimize
that
by
doing
all
the
reorganization
that
he
needs
like,
I
think
he
did
a
bunch
of
stuff
in
the
vfs
layer
with
like
the
way
that
you
know
the
zfs
file
or
zfs
inode
stuff
is
declared
so
similar.
Things
like
that
would
make
sense
for
delos
and
other
new
platforms
as
well.
B
Yeah,
that's
exactly
the
approach
we
took
for
freebsd
and
I
think
it
worked
out
pretty
well,
I
mean
we
can
even
go
as
far
as
if
there
are
interfaces
that
need
to
be
refactored
for
delos
or
whatnot
like
we
can
make
those
changes
in
the
open
repo.
So
you
can
just
drop
in
the
code
you
need
when
it's
ready.
B
We
did
that
for
freebsd,
where
we
knew
changes
were
going
to
be
coming
and
it
was
easier
for
you
to
add
them
later,
but
yeah
basically
try
to
all
tackle
all
those
things
first
and
all
the
refactoring.
So
it's
easier
to
just
drop
it
in
at
the
end
and
add
the
the
if
deaths
as
needed,
or
what
not
another
thing
we
did
in
conjunction
with
that
was
update
the
test
cases
so
that
they
could
run
on
the
other
platform.
So
I
mean
we
could
bring
in
that
kind
of
functionality
sooner
too.
C
Thank
you.
Yes,
I
will
try
to
split
some
of
changes
and
propose
to
some
updates
for
platform
identification,
because
right
now
you
try
to
identify
a
platform
by
your
name
code.
But,
as
you
know,
linux
can
be
different,
davian,
santos
or
something
else
also,
it
will
be
tried
to
much
more
better
identify
as
some
small
of
platform,
for
example
linux,
debian
linux
and
those
freebies
d1
version
3bd,
another
version
and
dos.
C
External
variables,
what
we
can
change
in
tests
where
we
can
use
it
on
different
platform
with
a
little
bit
different
names,
and
in
this
logic
we
have
split
it
to
some
of
changes.
What
I
would
like
to
provide
it
is
why
I
try
to
ask
first:
how
try
to
do
it
better,
try
to
partly
of
components,
try
to
part
of
test
cases,
because
it
will
be
much
more
easy,
try
to
discuss
of
our
updates
and
for
all
platforms,
and
I
would
like
to
have
all
visions
to
integration.
C
Also,
brian.
We
discussed
it
about
additional
billboards
where
we
tried
to
recheck
of
some
solution
between
linux,
bsd
and
dealers,
and
in
this
case,
how
deals
is
different
with
the
lumos
right
now
we
are
using
the
same
of
tools.
What
is
linux
use,
for
example,
corrupt
use
and
other
tools,
like
grape
said,
avocado
and
another
tools
with
the
same
flags.
It
is
why
dealers
as
a
platform
will
be
a
good
in
open
cfs
code,
because
deals
is
different
in
many
places.
B
B
C
A
Especially
from
the
testing,
you
know
userland
point
of
view.
You
know
maybe
someday
there's
like
a
the
lumos,
the
the
openstack
s3
both
supports
illumos
and
dil
dillos,
and
they
both
have
the
same
kernel.
You
know
they
both
build
the
kernel
the
same
way,
but
they
have
different
because
their
user
lands
are
so
different.
Then
you
know
maybe
the
the
test
suite
needs
to
detect
them
as
different
platforms.
Right.
C
Yes,
it
is
why
I
try
to
propose
to
use
the
devos
as
a
separate
platform.
Also
illumis
missed
and
many
open
cfs
switches.
What
I
have
ported
to
device
where
we
can
try
to
tests
and
try
to
find
additional
issues
on
deals,
because
we
are
faster
in
threats
than
others
and
additional
platform
can
show.
We
try
to
find
out
additional
issues
and
we
are
all
wants
to
see
the
effects
much
more
better
and
stable.
A
Yeah
I've
been
continuing
to
work
on,
read
the
expansion
the
past
month,
not
so
much
but
a
bunch
before
that,
and
I
I
do
hope
to
finish
it
up
very
soon.
It's
basically
all
working,
I'm
going
through
and
doing
like
code
cleanup
upstreaming,
some
some
things
that
were
not
kind
of
core
to
rid
the
expansion
which
you
probably
saw
in
the
past
month
and
those
all
went
in
so
now.
I
think
the
the
next
steps
for
me
are
like
continuing
code.
Cleanup.
Writing,
writing
up
your
documentation.
A
C
C
C
C
We
have
to
limit
to
use,
only
define
your
drives
and
the
server
and
not
to
use
all
available
drives
on
the
server
try
to
filter
out
some
of
changes
and
another
one.
It
is
how
much
cpu
we
can
use
under
vm,
because
on
different
platform,
we
see
some
limitation
of
threats
and
something
of
tools
can
be
crushed
and
crash
of
the
system.
A
C
Yes,
I
will
try
to
upstream
our
changes
and
okay
yeah
yeah
yeah.
I
will
show
where
we
are
not
available
for
for
all
changes
and
also
additional
issue.
It
is
on
dealers.
We
are
using
an
native
zfs
model
in
kernel.
It
means
we
have
a
bootable
system
with
zfs
and
another
tests
and
another
tool
with
changes
in
global
variables,
and
there
are
global
variables
can
impact
our
pool
and
data
sets
what
we
try
to
use
for
additional
artifacts.
A
Cool,
I
have
one
more
question
from
someone
else
here.
So
I'd
like
to
give
time
for
other
folks
to
ask
questions
as
well,
but
thanks
a
lot
for
those.
You
know
that
sounds
like
you've
encountered
a
lot
of
different
issues
and
fixed
a
lot
of
them.
So
we
definitely
look
forward
to
seeing
the
you
know,
issue
issue
reports
and
prs
from
that.
Yeah.
C
A
E
E
I
don't
want
to
change
the
default
because
these
people
are
used
to
it,
but
a
way
to
opt
out
of
that
to
make
it
faster
is
a
issue
I've
been
encountering
where
in
systems
with
very
large
numbers
of
snapshots,
sometimes
way
more
than
there
should
be
that
you
know
trying
to
destroy.
Some
of
those
snapshots
can
take
in
excruciatingly
long
time.
A
C
B
A
E
A
E
E
C
E
E
A
A
Yeah
yeah,
where
it's
like
dash
v,
is
like
hey
like
all
of
them.
I'm
just
a
human.
Give
me
some
info.
You
know
I'm
trying
to
figure
out
what's
going
on
here
and
then
having
a
special
flag.
That's
maybe
a
long
off
like
you
know,
zfs
destroyer
dash
dash
list
dash
names.
That's
like
I
want.
I
know
that
I
just
want
this
specific
thing,
which
is
the
names
of
the
snapshots
that
are
going
to
be.