►
From YouTube: March 2022 OpenZFS Leadership Meeting
Description
Agenda: compression; review requests
https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit#
A
All
right,
let's
get
started.
This
is
the
march
now
march.
2022
opens
the
fest
leadership
meeting.
I
want
to
start
off
just
by
saying
that
you
know
I've
been
following
the
news
in
in
ukraine,
and
I
know
that
there's
a
number
of
developers
in
our
community,
from
ukraine
and
from
russia
and
just
wanted
to
say
on
a
personal
level
that
it's
a
real
shame
what's
happening
there,
and
I
hope
that
all
of
your
all
of
you
and
your
families
are
safe.
If.
A
B
C
B
B
The
first
one
was
a
small
one
that
a
customer
did,
I
think,
back
in
the
summer,
just
basically
the
startup
service
script
to
be
able
to
load
and
unload
encryption
keys
automatically
at
boot
for
their
database
and
so
on,
and
I
think
that
was
just
a
matter
of
that
ending
up
in
the
contrib
directory
or
something
like
startup
scripts.
Normally
do.
A
A
A
B
B
D
Oh
yeah,
I
that's
exactly
what
I
told
and
I
remember
matt.
You
was
working
on
that
before
so
that
every
completed
right
should
decrement
the
amount
of
dirty
data
yeah.
So
it
should
be
pretty
smooth.
That's
either
something
got
broken
or
some
kind
of
traffic
is
not
accounted
there.
Maybe
de
dupo
or
I
don't
know
what.
E
D
A
D
A
A
So
if
you're
seeing
that
like
all
the
time,
then
we
probably
want
to
look
into
that
because
that
will
be
a
you
know,
a
bigger
improvement
once
that's
working,
then
you
should
only
have
that.
Like
remainder,
like
alexander,
said
that
is
dropping
quickly
and
then
you
know,
there's
definitely
fluctuations
but
they're
much
more
minor.
Normally,
you
know
like
at
the
very
end
of
the
txg
you're
not
sinking
as
quickly
because
you're
waiting
for
the
last
few
things
to
happen.
B
B
A
A
B
B
A
60,
okay,
so
yeah,
so
it's
not
even
until
you
get
60
dirty
that
there
should
be
any
delay
but
depending
on
the
time
scale
there
like
it
may
be
that
all
the
applications
threads
are
like
waiting
for
ios
to
complete.
Do
you
know
in
your
graph
there?
What
is
the
time
scale
like
the
kind
of
period
of
that
oscillation.
A
Yeah,
so
if
that's
the
case,
then
that
could
easily
be
like
the
max
delay
being
100
milliseconds.
It
could
be
like.
Okay,
all
your
applications
are
in
there
they've
hit
the
max
delay,
100
milliseconds,
and
now
they
can't
do
anything
for
100
milliseconds,
even
though
stuff
has
been
flushed
out.
You
know
when
we
wrote
this.
Originally,
it
was
in
the
context
of
spinning
disks.
A
If
you're
running
on
ssds,
it
could
easily
be
the
case
that,
like
that
100
millisecond
delay
is
just
like
ridiculously
long,
and
you
know
I've
seen
this
a
lot
on
ssd
pools
where,
like
the
txgs,
can
sink
very
quickly,
because
you
know
the
max
dirty
date
is
four
gigs
like
it
doesn't
take
that
long
to
write
out
four
gigs.
If
you
have
a
bunch
of
ssds,
so
you
know
you
can
kind
of
work
around
that,
probably
by
like
decreasing
the
max
delay
as
kind
of
a
stop
gap.
B
D
Alan
it
just
got
to
my
mind
since
you
you
say
you
have
so
many
threats.
It
may
happen
that
if
all
of
the
threat
came
same
time
and
each
of
them
will
increment
weight
more
and
more
and
more,
the
last
will
get
queued
in
situation
when
first
haven't
even
yet
completed.
So
practically
your
delay
is
not
increasing
gradually,
but
it
just
goes
all
the
way
to
the
max
and
then,
as
matt
told
you
get
some
100
millisecond
delay
when
really
everything
is
blocked,
so
would.
B
B
A
I
think
that
alexander,
I
think
that
the
the
fix
would
probably
be
like.
Probably
what
we're
doing
is
you
know
when
you
check
how
much
delay
you
should
have
it's
based
on
like
the
amount
of
dirty
data
right
but,
like
you
said,
threads
might
have
been
allowed
in,
but
they
haven't
yet
actually
dirtied
their
data,
so
we
probably
would
need
something
where
it's
like.
Okay,
like
you're
coming
in
you're,
checking
the
amount
of
dirty
data.
You
want
to
dirty
some
data,
however
much
data
you
want
to
dirty.
C
A
Yeah,
I
think
that
would
be
like
the
right
solution
to
having
a
lot
of
threads
there's
other
things
in
there
that
are
supposed
to
handle
like
having
a
lot
of
threads
like
once.
You
start
delaying,
then
the
delay,
then
it
should.
It
should
kind
of
the
delay
should
work,
irrespective
of
the
number
of
threads
like.
If
you
have
a
lot
of
threads,
then
it's
like
in
the
delay
is
one
millisecond
then,
like
the
first
thread,
waits
it.
A
If
all
threads
come
in
the
same
time,
you
wait
a
millisecond,
then
one
thread
gets
to
do
something
then
another
millisecond.
Then
another
thread
gets
to
do
something,
so
you
can
put
it
like
that,
but
the
the
window
there
like
you're,
saying
between
when
you
check
and
then
when
you
go
and
dirty
it-
could
allow
a
lot
of
threads
in.
D
D
A
C
A
B
B
A
D
And
in
context
of
delays
being
sequential,
I
was
thinking
that
somehow,
maybe
it
would
be
great
to
have
them
working
in
parallel.
For
example,
if
you
have
one
tray
doing
large,
big
rights
and
other
doing
a
lot
of
small
rides
now
they
all
get
serialized
into
the
same
line.
At
the
end,
bandwidth
of
the
thread
doing
large
right
will
be
much
higher
because
they
are
all
waiting.
All
practical.
All
of
them
have
insane
iops.
A
D
It's
a
bit
weird,
so
I
haven't
got
good
ideas
how
to
like
from
what
then
base
the
delays,
because
if
we
put
them
all
from
current
time,
not
from
the
last
one,
then
it
will
be
slightly
on
the
other
side.
More
trades
will
be
able
to
push
more,
but
maybe
it's
actually
okay.
They
will
just
put
more
into
dirty
data
and
then
get
all
throttled
at
the
end
as
a
result.
A
Yeah
then
you
I
mean
the
obvious
way
of
deserializing
them
runs
into
the
problem
of
like.
If
you
have
more
threads,
then
you're
like
letting
more
io,
go
through
right.
If
every
thread
gets
the
same
delay
from
the
starting
point
then
like
having
more
threads
means
you
get
to
do
more
work
at
that
amount
of
dirtiness.
A
A
B
A
A
A
B
Down
yeah
with
the
minimum
turn
down,
but
the
idea
is
that
there's
no
delay
at
all,
and
then
you
hit
that
threshold
where
the
delay
kicks
in
and
that,
then
we
have
that
exponential
curve
or
whatever
there,
that
that
increases
the
delay
as
your
jks
dirty
data
value
gets
higher.
So
once
you've
gone
up
that
line.
What
this
patch
does
is
that,
after
you
drop
below
that
threshold,
instead
of
going
back
to
zero
delay,
it
does
the
yellow
line
of
keeping
an
amount
of
delay
on
until
you've.
A
But
I
feel
like
this
is
kind
of
a
hack
around
the
real
problem
of
like
why
did
like.
If
you
had
this
high
workload,
why
did
the
amount
of
dirty
data
ever
go?
Does
it
like
ever
go
down
that
low?
It
should
have
been
able
to
keep
it
high,
but
the
reason
we
didn't
keep
it
high
is
because
we
applied
too
much
of
this
delay.
A
A
D
A
Yeah
like
there's:
if
there
wasn't
this
issue
with
like
like
a
gajillion
threads,
then
you
know
when
you
get
down
to
zero
and
you
in.
If
we
said:
okay,
fine,
like
you,
can
go
jump
up
to
30,
dirty
instantaneously,
that's
fine
and
then
like
right
and
then
now
you
start
having
a
delay
right
like
you.
There
should
be
a
need
to
like
delay
from
zero
to
30
and
then
start
to
you
know
you
should
be
able
to
get
to
30
start
delaying.
Then
you
have
more
or
less
the
same
behavior.
A
A
D
Maybe
you
could
collect
put
to
the
same
graph
just
by
understanding
different
states
of
transaction
group
processing,
sync
processing
when
it
started
when
it
finished.
When
it
started
cache
flashing,
maybe,
and
also
out
there
average
delay
with
some
sampling
or
like
something
like
that
to
see
whether
it's
delay
a
problem
or
it's
a
problem
of
releasing
fs
going
to
some
slow
stages.
And
then
it
has
to
accumulate
more
data
that
actually
causes
throttling.
B
D
I
mean
I
meant
more
like
try
to
correlate
delays
with
exactly
what
zf
is
doing
at
this
point,
whether
it's
writing
data,
whether
it's
starting
flashes
or
or
for
the
devs
updates
of
last
stages
of
sync
updates
of
labels
or
uber
blocks
whatever
and
just
to
perceive
on
that
graph
where
exactly
it
starts
throttling.
Maybe
it's
valid
pulsation.
Maybe
it
will
just
have
very
long
sync
time
for
caches
cache,
flash
time
or
something.
A
A
Like
if
you
only
have
16
threads,
I
would
think
that,
like
you
know,
the
amount
of
dirty
data
is
like
going
up
and
up
and
up
and
then
like
you,
get
to
like
one
millisecond
delay
and
like
isn't
that
like?
Is
it
shouldn't?
One
millisecond
delay
be
plenty
enough
to
kind
of
bring
the
incoming
amount
of
dirty
data
very
low,
because
you
know
you
only
have
16
threads
and
you
have
one
millisecond
delay.
You
can
only
really
accepting
one
operation.
Every
millisecond.
A
A
D
Just
a
last
comment:
I
just
looking
now
on
the
graph
on
its
right
side
and
they're,
pretty
small
amount
of
dirty
data
that
grow
or
delay
from
10
millisecond
to
100
milliseconds.
It's
really
only
like
five
percent.
Just
looking
on
the
graph,
I
don't
see
numbers
they're,
pretty
tiny
there,
and
maybe
that
or
actually
five
percent
is
that
what
16
threads
can
actually
drop
in
the
last
moment,.
D
A
And
then,
because
the
delays,
if
you
have
multiple
threads,
because
the
delays
kind
of
compound
it
shouldn't
matter
that
you
have
a
bunch
of
threads,
you
know
like
it's.
The
delay
is
basically
like.
We
only
take
one
operation,
every
10
milliseconds,
regardless
of
how
many
threads
you
have
like
that,
should
make
you
really
really
slow,
but
maybe
there's
somebody
to
circumvent
that
if
you
have
a
lot
of
threads
and
it's
not
like
the
check,
isn't
working
right
or
whatever
well,.
A
B
Part
of
what
we
saw
there
was
if
there
was
a
quota
or
something
on
a
data
set
that
we'd
end
up
having
to
stop
and
wait
for
the
currently
pending
stuff
to
flush
out
before
we
could
write
more
data
to
it
and
it
would
get
really
really
slow
because
it
was
every
amount
of
data
you're
trying
to
write.
It
was
just
blindly
multiplying
it
by
24..
B
A
B
So
that
was
the
first
change
was
just
that,
because
we
don't
have
ditto
blocks
anymore.
We
didn't
need
an
extra
multiplied
by
two
that
was
in
the
formula,
so
the
default
value
could
go
down
from
24
to
12.
but
yeah.
I
wasn't
sure
there.
So
I
we,
but
we
basically
don't
use
the
the
tunable
anymore.
So
we
should
probably
garbage
collected
if
it's.
B
B
A
B
A
B
B
A
A
B
It's
basically
the
same
way
that
you
can
delegate
a
data
set
to
a
zone
or
a
jail
on
lumos
and
freebsd.
You
can
do
that
to
a
namespace,
a
username
space
on
linux,
so
that
root
in
that
username
space
can,
you
know,
do
zfs
commands
on
that
subset
of
datasets
and
it
takes
care
of
the
the
uid
mapping
stuff
that
linux
supports
where
each
namespace
has
its
own
range
of
uids.
That
map
to
the
typical
range.
C
So
I
made
a
couple
passes
at
it.
I
think
it's
looking
pretty
good.
We
had
a
couple
open
questions
that
I
don't
know
that
we
came
up
with
any
good
solutions
for
really
but
they're
they're,
probably
not
big
deals
and
things
we
can
live
with
so
it'd
be
great
to
get
additional
eyes
on
it,
but
I
think
it
looks
pretty
good.
C
C
A
Okay,
maybe
for
for
review
purposes.
You
know
if
you'd
like
to
have
folks
review
that
you
know
the
command
line,
interface,
user
interface,
which
seems
like
a
good
idea.
Could
you
write
that
up
in
the
first
comment,
like
I
see
in
the
first
comment,
it
just
says,
like
oh
zfs
userness
attach
like
some
random
number
and
then
a
you
know:
data
set
name.
So
it
would
be
nice
if
you
could
put
like
you
know,
maybe
the
rendered
man
page
or
like
a
description
of
like
here's.
A
Especially
for
overlook,
if
we're
like
you
know,
it's
kind
of
related
to
zfs
zone
or
whatever
the
most
folks
might
have
thoughts
on
you
know
their
experience
with
that.
I
don't
know
right,
you
know
maybe
they're
like
oh,
that
command
is
actually
really
hard
to
use
you
should
have.
We
should
have
done
this
other
way.
Maybe
you
can
fix
that
or
something
I
don't
know.
B
C
A
A
C
And
anybody
can
do
their
reviews
too
right
if
they
want
to
comment
things
and
look
at
stuff
right.
I
know
alexander's
had
some
peers
outstanding
for
a
while
now
that
you
know
he
was
looking
for
reviews
months
ago
and
there's
there's
lots
of
out
there
that
are
like
that
for
cool
features
and
cool
functionality.
They
just
need
more
eyes
on
them
right,
yeah,.
D
D
Say
I
have
twelve
seven,
eight
nine
improved
log
space
map
load
time
which
hangs
like
for
three
months.
We
are
already
including
it
in
our
releases
and
obviously
would
like
to
have
it
upstream
at
all
at
very
least
some
eyes
on
it.
Just
in
case
I
missed
anything
like
it
works
for
us,
but
best
eyes
are
always
good
to
have.
A
A
D
Like
there
are
like
general
problem
is
that
there
is
no
upper
limit
for
number
of
dirty
space
maps,
so
if
we
have
huge
pool
unless
there
is
upper
limit,
but
it
scales
with
number
of
v
devs
if
number
of
vdfs
goes
to
like
hundreds,
many
hundreds
or
thousands,
then
a
number
of
dirty
space
map
can
reach.
I
don't
remember
dozens
of
thousands.
A
D
It's
practically
require
a
head
seek
for
each
of
them
to
read
them
on
full
import
and
then
cpu
time
to
process
them
and
question
whether
it
makes
any
sense
to
have
so
many
of
them
before
flashing
into
from
space
map,
lock
into
main
space
map,
storage
and
yeah.
In
my
limit
in
my
patch
I'm
doing
by
addressing
from
two
sides
from
one
side,
I'm
limiting
maximum
lifetime
of
log
to
100
transactions
or
transaction
groups
so
that
they
never
accumulated
too
much
from.
E
D
Side,
I
am
implement
I've
implemented
parallel,
read
of
log
of
the
log,
so
that
like
this,
I
can
accumulate
or
amortize
all
the
read
latencies.
So
it's
practically
get
cpu
bound
even
on
hard
disk
pools
for
csd,
it's
not
so
dramatic,
but
for
for
hard
disks,
very
latency
is
substantial
and
there
I
see
like
10
times,
improvements
and
more
cool
partially
because
of
latency
reduction
partially
because
of
maximum
history
length
reduction,
so
both
sides
help
and
to
me
it
doesn't
look
controversial
or
questionable
it's
more
like
in
case
I
missed
anything.
A
A
D
A
A
D
A
A
E
Hey,
I
threw
two
small
review
requests
into
the
agenda
notes.
First,
one
is
on
supporting
incremental
receive
of
clone
streams.
I
think
we
talked
about
that
recently
and
the
other
one
alone.
Is
this
one?
It's
getting
fairly
old.
Now
it's
a
pretty
hkc
race,
condition
between
cfs
z,
get
and
cfs
z.
Note
dmu
fini!
E
A
You
can
ping
them
for
sure
all
right.
This
is
probably
a
good
place
to
end
the
meeting,
thanks
for
all
the
contributors
work
on
that
I
know
the
pride
you
know,
the
the
leaders
and
other
project
contributors
have
been
a
little
slow
on
getting
these
things
reviewed
and
merged.
Hopefully
we
can
pick
it
up
a
little
bit
in
the
next
few
months,
but
thanks
thanks.
Everyone
see
ya.
Thank
you.