►
From YouTube: OpenZFS 2021 Hackathon Presentations
Description
From the 2021 OpenZFS Developer Summit
Details: https://openzfs.org/wiki/OpenZFS_Developer_Summit_2021
A
B
The
last
time
I
was
talking
about
brt,
we
had
one
pretty
big
pending
problem,
how
we
can
avoid
overhead
on
when
we
are
free,
freeing
blocks
so
because
with
brt
we
cannot
rely
on
the
like
dedupe
bit
set
in
the
block
pointer.
So
we
actually
on
everything,
have
to
go
and
check
if
we
don't
have
to
update
the
brt
table.
So
I
found
the
solution
to
that
some
time
ago.
B
I'm
just
dividing
all
of
e
devs
in
regions
like
one
gigabyte
regions
and
I
and
I
keep
a
counter
reference
counter
for
every
region.
So
this
reference
counter
for
the
region
is
a
sum
of
all
brt
counters
for
every
block
in
this
specific
region,
and
I
can
keep
those
counters
in
memory
because
they
take
very
little
memory.
B
So
it's
very
little.
So
I
can
keep
those
in
memory
and
so
then,
what
I
have
to
free
the
block.
I
just
consult
this
regions
counters
and
if
it's
zero,
then
there
is
nothing
to
do.
If
it's
more
than
zero,
then
possibly
the
given
block
is
in
brt.
So
then,
I
have
to
go:
look
up
the
entry
and
update
the
entry,
so
so
this
pretty
much
fixes
the
problem.
B
B
So
we
can
have
the
same
block
in
both
tables
at
once.
So
alan's
idea
was
to
check
the
bit
and
if
we
have
the
duplication
bit,
then
the
block
is
already
in
the
duplication
table.
So
there
is
no
need
to
create
an
entry
in
brt
table.
We
can
just
bump
the
reference
counter
in
the
ddt,
so
this
basically
means
that
using
prt
we
do
manual
the
duplication.
B
B
B
B
B
B
A
B
C
So
as
we
talked
about
a
little
bit
yesterday
during
the
hackathon
planning
session,
the
automated
prs
that
get
filed
or
the
automated
test
runs
that
get
started
when
you
file
a
pr
against
the
opencfs
repository
are
a
good
idea
in
theory,
but
in
practice
they're,
basically
always
read,
and
the
reason
is
that
we
have
a
number
of
flaky
tests
and
we
have
a
number
of
issues
that
crop
up
from
time
to
time,
and
one
of
the
things
we
talked
about
improving
was
trying
to
get.
Those
automatic
test
runs
to
be
more
useful.
C
C
So
what
I'm
doing
here
is
I'm
running
a
single
test,
suite
the
case,
normalization
suite
and
it
has
a
few
known
failures
in
it,
and
so
you
can
see
now
we
have
a
couple
tests
coming
that
have
failed
and
once
this
initial
set
finishes,
we
automatically
rerun
all
the
failing
tests,
along
with
the
necessary
setup
and
cleanup
steps,
and
then
at
the
end
you
get
the
results
summary
and
it
informs
you
hey.
These
are
expected
failures
and
we
didn't
have
any
unexpected
failures
in
this
run.
C
This
work
is
partially
based
off
of
an
almost
pr
with
some
slight
tweaks
to
make
it
a
little
bit
more
usable
for
the
automation,
workflow
and
then
there's
also
some
changes
to
the
github
workers
to
make
them
automatically
use
this
flag
and
then
another
change
that
needs
to
be
made
in
the
buildbot
repository
to
make
all
the
different
builds
use
this
flag.
But
a
pull
request
has
been
filed
for
this
and
it
is
visible
on
github.
So
if
people
want
to
take
a
look
to
code,
they
can
that's
it
thanks.
D
Samsung
pm1725bs
like
I
said
something
interesting
that
we
see
with
a
different
nvme
drive.
We
see
with
the
certain
keyoccia
drives
that
the
read
and
write
bandwidths
are
pretty
close
to
each
other
as
we
vary.
The
percentage
of
jobs
that
are
writing
versus
reading
so
here
with
zfs
will
probably
be
around
the
10
to
20
of
writing
jobs
here.
D
Where
on
this
graph,
you
can
it's.
On
the
left
hand,
side
of
the
dotted
line
for
each
of
these
graphs
is
the
rebuild
performance.
The
left
whole
graph
is
the
read
and
the
bandwidth
and
the
right
whole
graph
is
the
right
bandwidth
and
we
still
see
like
350
meg
per
second
rebuild
right
bandwidth,
which
was
the
same
thing.
D
We
instead
of
doing
one
right
every
n
time
we
said
hey,
let's
write
a
certain
amount
of
you
know:
data
like
two
gigs
or
eight
gigs
per
end
time,
and
then,
when
we
saw
that
and
when
we
tried
that
we
saw
that
the
right
bandwidth.
So
actually
it
raised
a
lot
to
about.
You
know
the
peak
there
in
the
light
red
graph
is
like
over
two
gigs,
a
second.
So
what
we
try?
D
What
we
thought
to
do
for
the
the
hackathon
is
to
try
to
emulate
that
functionality
in
zfs,
instead
of
just
kind
of
writing
rebuild
rights
kind
of
haphazardly,
so
to
speak.
We
said,
let's
group,
a
bunch
of
them
up
together,
that
that
amount
being
adjustable
by
a
certain
parameter
and
then
issuing
that
to
the
device
and
to
kind
of
explain
what
we
did
there.
I
had
to
hand
it
over
to
brian.
If
he's,
if
he's
there.
E
Yeah,
so
what
trevor
and
I
experimented
with
today,
is
basically
trevor's
actually
put
a
lot
of
work
into
this.
Prior
to
today,
he
took
the
time
to
split
up
the
veto,
rebuild
queue
originally
in
zfs
the
reads
and
the
rights
they
were
being
placed
in
the
same
queue,
and
so
what
he
took
the
time
to
do
in
previous
work
was
actually
split.
Those
two
things
apart
and
so
today,
since
we
had
the
separated
queues,
we
basically
identify
okay.
If
this
is
a
right,
let's
just
go
ahead
and
first
identify
have.
E
A
So
I
was
working
on
triaging
prs
and
also
making
putting
together
the
videos
from
yesterday.
So
brian
and
mark
helped
me
with
this.
We
went
through
the
oldest
prs
and
we
got
through
one
page,
the
last
page
of
pr's.
We
got
through
looking
at
all
them
and
we
found
some
that
probably
just
need
to
be
closed.
A
We
added
a
few
to
this
spreadsheet
of
almost
done
ones
that
like
need.
You
know
a
little
bit
more
reviews
and
contacted
folks
on
that
and
that's
about
it,
and
then
I
also
worked
on
the
video
for
from
yesterday,
remembering
how
to
use
imovie
and
what
my
workflow
was
from
last
year.
I'll
show
you
so
you
know
I.
G
F
A
G
I
went
and
checked
this
morning
and
if
you
want
to
add
a
new
option
which
I've
been
trying
to
do
a
little
while
back
it's
a
pain
because
all
of
the
intuitive
options
are
taken
and
you
would
like
to
have
long
options,
and
so
that's
what
I
did.
I
added
long
options
to
zdb
so
that
you
can
do
stuff
like
this
dash,
dump
debug
message
or
dash
dash
overblock.
A
H
H
We
just
need
to
modify
a
lot
of
the
fio
sort
of
parameters
and
how
we
kind
of
build
up
the
z-volts
instead
of
data
sets,
and
so
so
that's
that's
kind
of
what
we
spent
time
today
kind
of
experimenting,
so
you
saw
the
command
I
just
ran.
I
just
kicked
it
off.
Basically,
given
a
couple
of
disks
to
the
to
the
test
and
the
test,
what
we
got
working
is
the
sequential,
writes
and
sequential
reads:
two
z-volts.
H
Maybe
yeah,
so
I
think
the
idea
is
that
we
were
able
to
prove
out
that
we
can
get
this
done
pretty
easily
for,
writes
and
reads,
and
we
can
go
go
through
the
rest
of
the
of
the
other
tests
right.
The
the
the
random
read
random
rights
and
then
the
the
cash
reads
and
such
hopefully
we'll
be
able
to
kind
of
wrap
this
up
and
then
have
a
pr
out
so
that
we
can
have
you
know
zevo
performance
coverage.
I
can
show
you
what
the
sort
of
the
results
look
like.
H
A
F
F
So
I
added
I
don't
know
if
we
want
to
come
up
with
a
different
name
for
the
property,
so
it
doesn't
get
confused
with
the
pool
alt
route.
But
for
now
I
just
created
a
property
called
alt
route
and
you
set
it
on
a
data
set,
and
it's
inherited
by
all
that
data
says
children
and
that
alt
root
gets
prepended
to
the
mount
point
property
before
it's
when
it's
generated,
so
it
actually
takes
the
pool
wide
alt
route.
F
Then
the
data
set
alt
root
and
then
the
data
set
mount
point
and
concatenates
those
together
to
make
the
the
mount
point
and
the
the
main
idea
behind
this
is
if
you're
zfs
receiving
data
sets
from
another
machine
that
might
have
the
mount
point
hard
set
to
something
like
slash
far.
You
want
to
make
sure
that
all
those
data
sets
under
your
backup
data
set
or
whatever
are
not
over
mounting
the
rest
of
your
system
or
otherwise
interfering
with
it.
F
I
I've
done
programming
a
bit,
but
nothing
on
zfs,
so
this
was
kind
of
a
leap
into
deep
waters,
so
I
figured
I'd
in
my
foolishness.
I
would
take
the
simplest
thing
to
start
with,
so
I
looked
at
the
the
pr
one,
one:
seven
eleven
introduce
v
dev
properties
and
figured
I'd.
Try
to
add
something
simple
like
I
had
a
few
test
cases
and,
of
course,.
I
I
So
I
manually
tried
the
commands
and
they
worked
so
then
I
tried
looked
at
the
code
to
see
what
all
the
other
properties
would
be
gettable
and
settable,
and
then
I
tested
each
one
and
of
course,
on
the
third
thing
that
I
tested,
I
had
some
great
excitement
and
by
excitement.
I
wish
I
did
not
have
that
excitement
if
you
set
the
path
to
something
random,
just
as
a
test,
it
accepts
it
and
if
you
reboot
and
the
path
is
something
random,
your
pool
not
load.
I
I
I
Ahead
and
do
that
that
sounds
like
it
should
be
easy
in
the
back
of
my
mind,
I'm
thinking
not
knowing
that
I
would
have
some
excitement
of
mandoc
being
a
new
format.
I
hadn't
looked
at.
So
of
course
it's
like
chinese.
I
mean
I've
done
html,
so
I
I
know
annoying
prefixes
and
suffixes
and
all
that
nonsense,
but
it
was
it
was.
It
was
a
fun
thing
to
edit.
Let
me
just
say
in
fun
by
not
fun.
I
So
I
added
edited
the
a
very
rough
update
for
the
man
pages.
I'm
sure
it
will
need
to
be
tweaked
and
I've
checked
that
in
and
for
forwarded
the
link
to
that
to
allen
and
I've
made
a
list
of
all
the
manual
things
I
did
for
the
testing
the
properties
and
I
think
I'll,
just
separate,
like
the
list
of
properties
into
the
ones
that
are
read
only
and
just
make
a
test
of
can.
I
Can
I
read
it
and
can
I
not
write
it
and
then
for
the
remaining
two
properties
that
are
remaining
properties
that
are
writable
I'll,
just
make
a
right
modify
test
and
this
in
a
perfect
world
I'll
have
that
done
tomorrow
and
realistically,
maybe
sometime
this
week,
and
that's
it
if
you
want
to
jump
into
a
project
like
this
from
xero?
It's
it's
it's
a
very
steep
learning
curve,
but
I
would
have
to
say
extreme
thanks
to
allen
for
his
patience.
So
thank
you
very
much.
A
A
Are
going
to
be
puzzles,
as
I
mentioned
earlier
today,
so
puzzles
these
wooden
puzzles
with
cool
cutout
shapes
with
the
theme
of
different
insects
and
bugs
and
cool
nature
stuff
and
we'll
have
two
prizes
or
two
winning
entries
from
the
quality
category
and
one
from
the
open
class,
and
we
need
a
few
more
votes
because,
right
now
we
have
a
tie,
a
few
more
votes
in
the
for
the
quality
things.
Okay,
now
we're
not
tied.
A
A
A
A
A
A
We'll
have
you
know
we'll
do
this
again
next
year,
hopefully
in
person
and
and
hopefully
in
person
and
online
combo
next
year
will
be
really
fun
and
we'll
send
a
survey
to
folks
with
kind
of
questions
about.
You
know
what
you
think.
We
could
do
better,
that
you
can
do
better
at
the
conference
that
you
can
submit
anonymously
that
hopefully
we'll
put
together
the
next
day
or
two.