►
From YouTube: July 2022 OpenZFS Leadership Meeting
Description
Agenda: OpenZFS conference; quota enforcement; ZED config; 2.2 release
full notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit
A
A
A
A
A
And
we
also
have
sponsorship
opportunities.
Obviously,
in-person
conferences
are
much
more
expensive
than
remote.
Converses
we've
raised
the
ticket
prices
only
slightly
to
150,
which
you
know
does
not
come
anywhere
close
to
covering
the
the
cost
of
putting
on
the
conference.
So
you
know
we
rely
on
sponsorships.
We
we've
had
a
lot
of
great
sponsors
in
the
past
and
we
hope
to
get.
You
know
some
solid
sponsorship
this
year,
financially
financial
sponsorship,
so
that
is
open
as
well.
A
But
if
you're
interested
in
sponsoring
email
us
or
if
you're
interested
in
speaking
email
me-
and
I
hope
to
see
you
all
there-
you
have
until
the
end
of
august
august
29th
to
submit
your
talks
and
we'll
be,
you
know
we
will
be
having
covid
protocols,
including
masking
and
hopefully,
testing
and
and
vaccination
requirements.
If,
if
we're
able
to
set
up
contact
with
a
third
party
to
do
like
you
know,
verification
of
that
info.
A
C
C
B
You
can
even
see
the
performance
dropping
to
like
single
digit
megabytes
per
second,
once
you
start
hitting
that
it's
a
little
bit
less
bad
with
the
lower
inflation
setting
for
when
zfs
assumes
how
badly
it's
going
to
lay
things
out
on
disk
that
helps
a
little
bit,
but
you
still
run
into
that
quota
and
it
gets
pretty
bad.
This
came
out
of
that
work.
We
were
doing
on
the
right
smoothing
and
it
turns
out.
The
problem
is
actually
the
same
quota
thing
applies
to
z-vols,
especially
when
and
in.
B
Case
you're
always
overwriting
right.
You
can't
you
can't
exceed
the
quota
on
a
z-vol
because
a
it
doesn't
have
a
quota
and
b
it's
you
can't
write
to
lbas
that
don't
exist,
and
so
you
can
actually
see
that
same
performance
problem
on
z,
vols,
where
basically
everything's
in
overwrite,
once
it's
relatively
full
and
that
turns
out
that's
what
was
actually
causing
the
right
stalls
where
it
would
just
be
like
a
big
chunk
of
time
where
you
couldn't
write
anything
more
because
the
thread
was
stuck
waiting
for
the
transaction
to
flush
to
see.
C
B
F
Considering
that
the
walls
can
be
seen
provisioned
and
oversubscribed,
but
whatever
quota
may
have
sensed
there,
so
I'm
not
sure
it
should
be
dropped
completely,
but
I
agree
that
some
some
relax
could
be
there.
Just
speaking
about
your
case,
have
you
said
kubota's
there
explicitly
or
apparent
data
set
or
somewhere.
D
B
It
it
looks
like
the
value
is
just
getting
populated
with
the
vol
size,
which
would
be
the
same
thing.
I
think
in
the
case
of
the
thin
provision
version,
but
we
should
test
that
and
make
sure
we
don't
cause
explosions
so
yeah
we
got
most
of
a
prototype
together.
We're
just
working
on
adding
the
test.
B
Cases
to
you
know
show
that
what
the
problem
is
and
how
we
fix
it
and
that,
like
mav,
says
I
want
to
make
sure
we
don't
do
the
wrong
thing
in
the
case
of
a
thin
provision
quota
because
yeah,
I
was
very
surprised
to
see
the
like
on
the
dsl
there,
the
dd
underscore
quota
being
set
to
a
value
for
a
z-volt,
because
you
know
you
can't
set
a
quota
on
his
evolve.
It
won't
let
you
so.
I
was
wondering
where
it
was
coming
from.
C
B
F
No
vmware
officially
declares
that
it's
one
of
each
of
the
ai.
I
forgot
what
it
is,
but
yeah
vmware
should
handle
that
it
should
freeze
vms.
It
should
do
that.
You
should
have
some
warnings
and
turn
us
on
freebsd
reports.
It's
rice,
kazoo
layer
like
like
water
usage.
You
can
see
that
from
initiator
site
how
close
you're
to
kuwata.
So
it's
supposed
to
all
work.
Yes,
it.
C
F
B
E
Yeah
wow,
can
we
be
intelligent?
Can
we
can
we
be
intelligent
about
it?
If
we
say
like
the
quota
quota,
size
is
larger
than
x
times
the
dirty
data
max.
Then
we
are
always
likes
and
otherwise,
like
we
scale
it
back
proportionally,
can
we
do
something
like
that,
or
does
that
not
make
sense?
Do
we
always
have
to
be
at
least
one
txt
over
for
it
to
work.
B
B
Just
based
on
what
the
quota
is
so
that
yeah,
if
you
set
a
quota
to
a
gig,
they
can't
go
more
than
like
100
megabytes
over.
But
if
you
set
it
to
a
terabyte,
they
can
go
some
gigs
over
and
in
the
end,
as
long
as
it's
never
more
than
I
don't
know,
six
percent
or
whatever
number
we
decide,
then
maybe
that
makes
sense.
E
C
B
C
B
Wants
to
change
like
how
many
errors
and
how
many
seconds
before
it
kicks
the
device
out
of
the
pool
right
now
in
the
lumos,
those
come
from
some
system
properties
or
whatever,
but
on
linux
it's
they're
just
hard
coded
as
like
10
errors
in
15
minutes,
or
something
and
yeah
we'd
like
to
be
able
to
change
that.
But
what
would
that
look
like.
C
Yeah,
so
this
is
actually
a
bit
of
outstanding
work.
That's
been
outstanding
since
the
zed
got
implemented
on
linux.
Originally
we
always
had
an
item
to
come
back
and
make
this
tunable
and
configurable,
and
then
we
never
did
it
never
bubbled
up
to
the
top
of
the
list,
but
I
think
that's
a
great
idea.
The
original
thinking
was
to
provide
some
kind
of
you
know,
live
config
file
in
etsy
or
whatever
that
could
tune
various
z
parameters,
but
that
was
just
an
initial
notion.
B
C
Yeah,
that's
an
option
too.
My
recollection
is,
there
were
only
maybe
three
or
four
things,
something
like
that
that
were
obvious
to
tune
and
what
the
right
values
for
them
wasn't
obvious,
either
right,
which
is
how
we
ended
up
with
the
current
defaults
like
well.
This
seems
reasonable
for
most
cases,
that's
really
something
you
can
dial
in.
I
mean
I
think
a
flat
config
file
would
be
fine
or
something
along
those
lines.
C
A
C
E
C
E
C
So
the
goal
is
to
put
them
somewhere,
you
know
or
they're
easier
to
tune.
I
think
that
would
be
fine
if
we
just
want
to
make
command
line
options.
That
seems
like
the
easiest
thing
to
do.
If
we're
only
talking
about
two
or
three
does
anybody
know
offhand
where
they're
set
on
illumos
or
where
they
come
from
on
a
lumos.
A
E
C
F
E
Well,
then,
if
you
wanted
to
use
it
in
production
with
a
different
value,
you'd
have
to
edit
the
services
file
for
the
the
zfsz
service
or
run
it
manually
right
now
you
can
use
like
we
can
still
have
the
service
file
source
in
environment
file
and
then
have
devoids
for
that.
I
think
they're
just
a
practice
for
demons
that
do
not
support
config
files.
C
Out
is
in
the
c
file,
and
not
just
one
more
z
script,
because
the
zed
doesn't
source
any
of
the
z
scripts
when
it
runs
right.
It's
just
a
binary
like
it's
launched
to
the
long
running
daemon,
so
it
never
looks
at
any
of
those
values
other
than
values
that
are,
you
know,
supplied
to
it
as
command
line
options.
C
Yeah,
there's
a
whole
fault
management
infrastructure
that
we
got
from
solaris,
that's
kind
of
partially
built
into
the
zed
where
it
does
things
like
opens
a
case
or
any
kind
of
failure
from
the
the
disc
and
associate
the
vents
with
it
and
eventually
resolves
it
by
doing
something
like
faulting,
the
disc
or
whatever.
So
it's
actually
quite
a
lot
of
state
that
gets
managed
internally.
D
Here
is
it
a
huge
complication
to
make
this
is
cool
properties,
because
the
pools
are
always
going
to
be
associated
with
the
family
of
devices,
and,
as
I'm
pondering
this,
I'm
wondering
if
there
are
a
family
or
tier
several
tiers
of
devices,
each
making
up
a
different
pool.
How
would
I
apply
a
different
set
of
settings
to
each
pool,
depending
on
this
attribute
that
we
want
to
have
some
control
over.
C
D
I
hope
I'm
not
stepping
on
any
territory
here,
but
I
I'm
the
individual
who
reached
out
to
allen
with
these
questions.
I
work
for
seagate
and
we've
noticed
a
couple
of
things
with
some
broadcom
iocs,
where
they're
mp3
sas
drivers
generating
info
level
messages.
There
isn't
a
genuine
error,
but
we've
got
no
way
to
it.
It's
completely
random
quantum
mechanics
or
something
like
that.
It's
deeply
embedded
in
broadcom's
ioc
no
other
file
system
that
we've
ever
worked
with
has
ever
had
an
issue
with
and
by
the
way.
D
This
is
specifically
looking
at
our
some
of
our
our
raid
light
products,
in
particular
core
vault,
which
I've
had
huge
success
for
in
the
web.
3
space
and
d
store
space,
we're
doing
10,
plus
petabyte
direct,
attach
file
systems,
but
there's
this
annoying
thing
that
comes
around
about
once
every
couple
days
we
get
several
instances
of
these
info
messages
coming
up
and
the
zed
daemon
doesn't
know
the
difference
between
these.
D
This
being
a
write
error
or
an
information
message
coming
up
from
the
mp3
mpt3
sas
driver,
it's
a
log
info
message,
and
basically
what
it
says
is
that
we
have
a
right
operation
in
progress,
a
cdb
right,
16
and
occasionally
the
target
says,
detects
something
that
is
like
a
checksum
or
something
and
asks
for
a
retry.
The
driver
does
it.
It
always
succeeds,
not
a
retries
and
a
right
retry.
But
a
re-transmission.
D
However,
though,
that
info
message
that
that
event
occurred
is
percolated
back
up
the
stack,
and
so
it
doesn't
happen
on
the
9400
class
iocs
that
it's
32,
I
forget
what
the
exact
part
numbers,
but
it's
it's
limited
to
a
handful
of
broadcom
ioc
chipsets
and
we
can't
fix
it
from
the
seagate
side
and
broadcam
has
been
scratching
your
head
over
it
for
for
five
months,
and
and
again
it's
not
indicative
of
an
error
per
se.
It
is
a
simple
thing
that
happens.
D
C
C
Yeah,
if
you
don't
mind,
I've
got
a
couple
questions
about
that.
So
so
my
recollection
is
the
nothing
should
percolate
up
through
the
zed
unless
at
least
on
linux,
we
actually
get
an
error
from
the
low
level
block
device.
So
either
we
got
an
error
back
returned
from
the
block
layer
right
as
an
eio
or
something
like
that,
or
we
legitimately
got
the
wrong
data
back
from
a
device
right
and
then
we
generate
a
checksum
error,
saying
like
yeah.
D
D
The
the
target,
in
this
case
the
the
seagate
sas
target,
says
something
wasn't
right
about
that.
I
I
I'm
missing
something
or
checksum
didn't
match.
Please
reset
the
driver.
Does
it
when
it
completes
the
driver?
No,
the
mp3
sas
driver
notifies
with
this
log
info
message.
I
can
give
you
the
exact
screen
and
give
you
a
live
demonstration
of
it
right
now.
D
I've
been
testing
it
all
day
again,
but
it's
also
interesting
that
their
broadcom
has
a
number
of
tools
that
the
store
cli
and
if
anybody
wants
to
duplicate
this
in
a
benign
context,
if
you
simply
use
the
store
cli
to
retrieve
error
counters
on
a
running
broadcom
hba,
it
will
generate
these
error
messages.
If
you,
if
you
request
the
error
counters
10
times
in
less
than
five
minutes,
you
will
fault
the
device
if
it's
in
a
z-ray
type,
config
and
no
no
device
error
has
has
occurred.
C
Yeah
I'd
be
interested
to
dig
into
that
a
little
bit
more
because
I,
like
you,
say
I
I
don't
think
that
should
percolate
up
beyond
the
driver
itself
right,
I
don't
think
the
higher
level
of
efs
should,
as
I
remember
the
code
right
now,
should
even
be
notified
of
it.
Nothing
should
notice
that
so
I'd
be
curious
to
know
where
the
vet
is
picking
up,
the
bearers
from.
C
D
It's
interesting
because
xfs
xt4
butter
fs,
none
of
them
pay
attention,
pay
attention
to
this
info
message.
It's
percolating
up
and
I
can
reproduce
the
same
thing
using
nothing
but
but
dd
and
the
events
still
take
place
and
never
a
bite
of
data
is
lost
or
or
requires
a
retry
from
dd
itself,
or
anything
like
that.
So,
in
the
simplest
use
case
possible
we're
streaming
rights
out
there
and
it,
depending
on
the
position
of
the
planets
or
something
like
that.
D
D
B
A
E
E
D
More
than
three
of
them
in
a
finite
period
of
time,
the
device
will
be
evicted
from
the
pool
it
provided.
If
we
are
running
in
a
raid,
z
or
a
d-rate
configuration
where
there's
enough
devices,
the
device
will
be
evicted
from
the
pool.
Okay,
issuing
a
z-pole
clear
brings
it
back
everybody's
happy
if
we
are
running
in
with
a
single
device
against,
so
we
just
created
a
zfs
file
system
on
a
single
scuzzy
target.
D
E
Yeah,
so
it
sounds
like
zed
said,
does
have
lot.
You
know
as
as
as
ryan
said
earlier,
zed
has
logic
to
to
do.
The
device
swap
device
fail
processing,
but
I
I'm
with
you
brian.
I
don't
know
where
this
information
is
coming.
We
need
to
probably
do
just
some
debugging
with
zed
to
find
out
how
these
events
are
being
handled
by
by
zed
and
and
because
it
sounds
like.
Maybe
this
is
just
a
bug.
D
Well,
I
knew
I
was
outside
of
my
lead
league
and
I
ran
to
allen,
and
but
we
want
to
do
the
right
thing
for
zfs
I
I
don't
want
to
do
a
cheat
in
any
kind
of
way.
However,
this
is,
I
spent
some
time
in
spectrologic
working
on
gfs
several
years
back,
so
that
I
want
to
do
the
right
thing
by
the
community,
and
I
I
understand
that
you
know
the
importance
of
not
fudging
this
to
make
one
shady
product
work.
C
C
If
you're
running
it'll
show
everything
that
kernel
modules
detected
and
the
zed
picked
up
on,
but
it's
also
got
a
stream
of
events
coming
from
udev
for
the
block
devices,
so
that
would
be
probably
a
spot
to
start
to
see
like
why,
which
one
of
those
horses
is
causing
the
is
that
to
be
aware
of
the
issue
that
would
at
least
give
us
a
spot
to
help
narrow
it
down
yeah.
It
doesn't
have
like
a
bug.
D
Yeah
and
like
I
said,
I'm
turning
to
alan
on
this
stuff,
I
want
to
do
what's
right
by
the
community,
but
so
far
it's
taken
us
a
lot
of
time
to
start
to
start
setting
up,
you
know,
seagate's
a
big
company
and
and
whatnot
and
just
getting
the
door
open.
So
we
can
start
peering
into
the
void.
I
am
not
qualified
to
make
these
decisions.
I
looked
at
it
a
little
bit
and
I
got
all
tangled
up
and
nuts
trying
to
figure
out
it
goes
into.
It
goes
out
as
of
the
zed
damon
traffic.
D
D
C
D
F
Maybe
I
already
asked
a
couple
of
times,
but
what
are
our
plans
for
2.2
or
do
we
have
any
schedule
to
plan
ahead
because
we're
doing
the
release
engineering
for
trunas?
We
wanted
just
to
know
what
what
to
expect
and
very
narrow
case
like
what?
What
shall
I
do
now
for
scrap
performance
optimizations?
C
C
You
know
I've
seen
quite
a
bit
of
interest
in
people
maintain
the
need
for,
like
a
longer
term
maintained,
stable
branch
like
the
two
one
was
going
to
be,
or
is
intended
to
be
at
the
moment
right
where
we
just
cherry
pick
more
stuff
into
it,
just
have
a
stable
base,
a
people
run
for
a
long
time.
I
don't
know
that
stops
us
from
taking
a
new
tutu
release,
though
people
think
that
it's
enough
interesting
stuff
is
in
there
to
warrant
us
making
a
new
release
and
maintaining
it.
F
C
Mean
if
we
stuck
with
our
previous
cadence,
it
would
be
about
november,
or
something
like
that.
We
would
probably
cut
a
2.2.
We
should
probably
talk
if
that's
a
reasonable
plan,
if
that
makes
sense
to
people
if
there's
enough
stuff
there.
You
know,
if
that'll
be
worth
cutting
a
branch
and
maintaining
it.
C
B
E
B
E
B
I
guess
what
the
timeline
timeline
would
be
good
for
you,
alexander,
like
I
know.
We
also
want
to
think
about
in
the
future
figuring
out
what
that
timeline
is
going
to
look
like
for
all
the
different
things
that
consume
it,
whether
that's
you
know
the
next
ubuntu
lts
or
freebsd
and
truenas,
and
so
on.
F
Well,
it's
impossible
to
predict
everything
like
we
are
for
scale,
which
is
now
in
nightlife.
We
plan
better,
I
think
in
in
august
or
just
pretty
soon
so
november,
maybe
already
not
so
far,
pretty
late
again
again
in
release
cycle,
but
still
probably
acceptable.
I
don't
remember
when
rhys
is
planned,
but
somewhere
in
q4,
so
I
think
november
would
be
not
bad.
C
I
mean
it
would
also
be
worth
taking
a
look
at
what
outstanding
features
we
have
that
are
pretty
close
to
completion
right
if
any
of
those
are
worthy
of
getting
some
effort
on
to
get
them
wrapped
up
and
merged
all
right.
I
know
there's
some
outstanding
container
work
too,
there's
quite
a
lot
of
open
pr,
significant
features
in
them
right.
The
range
the
expansion
work
right
would
be
great
to
wrap
up
the
whole
bunch
of
things
that
fall
in
this
category.
C
C
So
I
guess
what
would
next
steps
be
there?
I
guess
I
could
go
through
and
make
a
list
of
like
major,
outstanding
features
and
kind
of
assess,
what's
currently
in
the
master
branch
right.
That
would
at
least
give
us
a
better
idea
of
what's
already
ready,
and
you
know
what
might
need
a
little
more
work.
C
Yeah
yeah,
I
believe
so
it'll
be
great
to
be
able
to
get
both
those
things
in
and
speaking
of
the
direct
I
o
stuff.
I
know
it
would
really
benefit
from
a
review
on
the
freebsd
side
too.
I
think
it's
been
heavily
tested
on
linux,
but
there
might
be
one
or
two
open
issues
still
with
freebsd,
we're
not
quite
sure
it's
behaving
right,
so
people
have
a
chance
to
look
at
it.
That
would
be
great,
but
I
know
we're
looking
for
reviews
for
that.
C
Yeah,
that
would
be
great
because
I
think
that
is
ready
to
go
too,
and
I
think
we've
got
a
couple.
Other
features
too
that
are
really
close,
ready
to
merge.
We
could
wrap
up
and
that
might
give
us
a
really
nice
two-two
release
with
a
bunch
with
enough,
but
not
too
many
features
right.
We
gotta
be
careful
about
piling
too
many
in
so.
C
E
B
B
The
my
review
request
for
the
spa
inflation
thing
where,
instead
of
just
statically
using
24
times
your
a
size,
it
actually
looks
at
the
v
dev
type
and
figures
out.
What
is
actually
the
inflation
is
going
to
be
so
that
you
don't
look
like
you're
going
to
go
over
the
quota
by
24
megabytes.
When
you
write
one
megabyte.
C
All
right,
so
I
could
take
a
look
at
some
of
those
things
looks
like
also
on
the
agenda
here
is
directory
scaling
yeah,
so
that
is
something
that
I've
looked
at
in
the
past.
You
know
what
things
and
my
experience
has
been.
It
actually
scales
quite
well.
Once
you
get
the
fat
zaps
at
least
the
the
insertion
removal
time
is
constant.
All
right,
we've
scaled
up
to
billions
of
entries
in
a
directory
right,
and
it
does
scale
at
least
that
far.
E
C
C
Yeah
yeah
but
like
if
you
saw
that
transition
at
a
thousand
arsenal
right.
It's
maybe
that
ballpark
right
and
maybe
things
have
changed,
but
my
recollection
has
been
that
we
saw
pretty
good
scaling.
You
know
once
it
did
that
conversion.
You
started
making
pat
sapps
it
scaled
pretty
well,
but
if
you
get
data
that
shows
differently
it's
something
we
should
probably
look
at
we're.
B
E
I
think
the
other
thing
yeah,
the
other
thing
is:
if
you
you
delete
files
from
a
directory,
the
the
zap
doesn't
shrink.
So
even
with
an
empty
directory
they
used
to
have
a
lot
of
entries.
You
could
get
run
into
some
performance
problems
that
way.
Yeah.
That's
a
that's
a
known
issue!
Wasn't
there
a
pr
for
that?
There's.
B
The
lumos
one
for
being
able
to
shrink
the
zap,
and
it's
been
on
my
radar
for
a
while
to
look
at
even
just
for
the
d-dupe
stuff,
because
you
have
the
same
problem
when
you
drain
your
d-dupe
thing
and
you
end
up
with
the
big
ddt.
Even
though
you
don't
have
any
entries
in
it,
and
in
particular
that
was
throwing
off
all
the
math
for
trying
to
figure
out
to
try
and
do
the
ddt
quota
stuff.