►
From YouTube: Second January 2023 OpenZFS Leadership Meeting
Description
Agenda: 2.2 branch; chacha encryption; raidz deflation; arc eviction
full notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit#
B
A
A
C
We
do
have
a
lot
of
stuff
in
the
master
branch
that
have
been
there
for
a
while,
including
overlay
support
and
some
other
features.
Really.
We
just
need
a
plan
to
to
wrap
up
that
work
and
make
sure
it's
in
a
good,
State
and
Branch.
It
make
sure
what
we
have
is
in
there
is
what
we
really
want
and
then-
and
you
know,
move
forward
with
that,
but
I
don't
have
an
exact
date
for
that.
Unfortunately,.
D
Like
are
we
waiting
for
some
specific
features?
Do
you
have
released
or
like?
What's
the
plan?
Why
not
start
it
at
any
arbitrary
point
like
nobody
is
screaming
really
and
I
I
I.
Personally,
no
and
I
systems
would
like
to
see
it
already
sometime
in
spring,
when
we
need
to
work
on
create
new
branches
for
doing
us,
both
scale
and
core
on
Linux
and
3bsd,
and
it
would
be
like
would
be
good
if
we
could
use
2.2
for
that
yeah
just
to.
C
I
know
that
we
were
really
close
on
a
bunch
of
them,
but
they
didn't
quite
get
there
block
cloning
was
one
of
them
was
ready
to
go
in
pretty
much
and
maybe
force
pool
exports
was
pretty
close
as
well,
and
I
wouldn't
want
to
make
a
branch
you
know
until
well.
If
we
made
a
branch,
those
features
probably
wouldn't
end
up
in
that
Branch
all
right.
C
D
E
C
F
So
basically,
for
me,
the
missing
item
was
zero
claim,
because
without
a
zero
claim,
we
cannot
really.
We
cannot
really
allow
to
block
phone
across
data
sets
and
I
think
that's
that
would
be
bad
so,
but
I
will
be
able
to
get
back
to
it,
probably
in
couple,
probably
in
a
month
and
and
finish
it
because
I'm
currently
working
with
on
a
different
project
with
Alan.
So
I
need
to
finish
this
this
one
first.
F
D
F
F
Well,
one
of
the
problems
is
that
when
I
sit
down
to
to
do
zero
claim
it
might
it
might
prove
itself
that
we
can
simplify
ziliary
records
because
my
initial
idea
well,
the
easiest
way-
was
to
simply
record
in
the
Zeal
ID
of
the
objects.
We
are
cloning
and
ranges
that
we
want
to
clone,
but
because
of
the
cross
data
sets
cloning
I
decided
to
to
record
in
the
Zeal
BPS
of
the
blocks.
We
are
cloning,
but
then.
F
So
and
because
this
is
implemented
that
way
that
we
record
BPS,
then
the
Replay
code
is
different
than
the
the
the
the
cloning
code
and
and
this
is
a
precedence
because
all
the
Zeal
replay
operations
are
basically
the
same
operations
that
are
used
during
normal
operations
and
block.
Cloning
was
was
different
in
this
regard.
But
if
we
can
do
that
from
Zeal
claim,
then
maybe
we
could
simplify
Zillow
records
and-
and
maybe
this
would
allow
us
to
use
the
exact
same
operation
for
for
clonic
and
for
cloning
replays.
F
Not
sure
sorry
I
wasn't
prepared
for
that,
but
I
can
talk
to
Alan
and
see
if,
if
maybe
the
current
project,
if
we
can,
we
could
make
room
for
for
this,
so
maybe
I
would
be
able
to
sit
and
work
on
this
earlier.
If
this
is
what
2.2
depends
on
that,
if
this
is
something
you
would
really
want
to
have
yeah,
but
with
my
current
obligations,
I
cannot
say
it
at
this
point.
If,
if
that
will
be
possible.
A
I
mean
that's
fine,
it's
just
it's
good
to
get
like
as
accurate
of
times
as
we
can.
When
we're
trying
to
plan
the
next
release.
I,
don't
think
that
you
know
I'm
fine
with
you
taking
the
time
to
get
it
right
and
not
have
to
do
like
rework
to
to
re.
You
know
read
your
things
after
it
gets
integrated,
Brian
I,
don't
know
what
your
things
are
on
that.
C
A
I
mean
I
kind
of
feel
like
we're
better
off
trying
to
cut
a
release
every
year
and
and
not
worry
too
much
about
holding
off
to
get
more
features
in,
especially
for
these
like
features
that
are
like
you
know,
they
take
a
long
time
to
develop.
They've
been
the
works
for
years
and
yeah.
It
might
not
get
it
didn't,
it
might
not
make
it
into
2.2,
but
there's
a
lot
of
other
stuff
that
is
in
2.2,
and
it
would
be
nice
to
get
that
out
to
a
release.
C
A
C
Agree,
the
current
a
lot
of
people
are
in
the
master
branch
and
it's
in
good
shape.
Now
so
there's
nothing
preventing
us
from
ranging
at
any
time
and
yeah.
We
could
certainly
we're
a
little
overdue
for
our
yearly
Cadence,
so
I
could
I
could
see
taking
a
2.2
now
with
you
know,
what's
in
master
today,
that's
well
tested
and
works
well
and
then
you
know
we
get
a
2.3
at
the
end
of
the
year
or
whatever,
with
this.
C
Well,
there's
there's
other
interests
in
making
a
2.2
from
just
a
maintenance
standpoint
right
like
back
forth,
you're,
getting
more
and
more
difficult
right
as
the
code
base
moves
more
and
more
forward.
So
there's
good
reasons
to
make
a
you
know
at
least
start
stabilizing,
a
2-2
Branch
off
master
for
people
that
really
test
yeah.
C
A
A
C
I,
don't
think
so,
so
this
was
a
a
bug
in
218
due
to
a
back
Port,
just
to
be
clear.
We
immediately
rolled
the
219
with
that
patch
reverted.
So
you
know
unless
you're
you're
running
the
master
Branch
at
the
moment,
which
still
has
this
code
in
there
until
we
merge
your
pull
request.
Matt
things
are,
should
not
be
an
issue
anymore
for
people
running
stable
releases
and
I
think
we
only
had
a
couple
reports
of
it.
So.
D
C
G
G
It
just
goes
straight
to
the
clinical
crypto
and
on
Linux
I've
implemented
a
module
for
the
ICP
to
do
the
work,
because
a
lumos
don't
have
that
the
those
algorithms
in
in
their
trees,
so
the
the
actual,
the
actual
Cipher
stuff
I've
taken
off
the
shelf.
So
it's
kind
of
all
there.
It's
all
written
up
in
the
in
the
in
the
pr,
so
it
mostly
I
mostly
just
need
guidance
on
you
know
where
do
I
take
it
from
here.
G
Deciding
if
you
know
how
do
we
decide
if
the
crypto
is
good,
you
know
it
can
have
all
the
right
words
on
the
packet,
but
if
it
doesn't
actually
print
it
out,
there's
not
a
lot
of
point.
The
actual
the
reason
for
wanting
this
is
just
for
devices
that
do
not
have
Hardware
accelerated
AES,
it's
very
slow
in
software.
So
that's
like
that's
your
Raspberry
Pi,
but
that's
also,
there's
a
risk.
G
A
Yeah
I
was
just
gonna
say
you
know,
we
I
think
we
would
probably
want
feedback
from
somebody
else
who
wants
this,
like
I
I,
think
I
understand.
You
know
the
use
case
that
you're
talking
about
it
makes
sense.
Theoretically,
it
would
be
good
to
have
like
other
examples
of
people
kind
of
like
upvoting.
This,
like
yeah,
like
I
I,
would
totally
use
this.
If
it
goes
in
and
then
you
know,
I,
don't
think
we're
gonna
review
the
cryptographic
code.
A
I,
don't
think
we
really
have
the
skills
or
time
to
do
that.
You
know
it
sounds
like
you
basically
copied
it
from
like
the
reference
implementation,
so
I
think
we'll
kind
of
trust
them.
Unless
anybody
knows
otherwise,
and
so
then
we
need
somebody
to
review.
You
know
the
kind
of
ZFS
specific
bits
of
this
which
it
looks
like
are
not
a
very
substantial.
D
G
I've
I've
done
a
very
only
the
most
lightest
of
testing,
which
is
making
sure
I
can
create
a
poll
on
one
and
import
on
the
other.
I
have
not
gone
further
than
that.
I
should
do
a
little
more
extensive
testing
but
I
like
there's
some
sense
of
Mercedes
and
bits
and
pieces,
but
I
yeah
I,
don't
know
how
deep
that
needs
to
go
to
feel
sort
of
confident
with
it.
A
Oops
sorry
and
we
I
guess
we'll
leave
it
for
you
to
work
with
other
folks
find
other
people
who
are
interested
find
someone
to
review
it.
I
think
I
didn't
already
assign
Mark
I,
think
Mark
would
be
the
signee
Mark.
Maybe
so
he
can
also
help
work
with
you
to
find
code
of
yours
looks
like
Jorgen
took
at
least
some
somewhat
of
a
look
at
it.
So
maybe
we
Jurgen
how
thoroughly
did
you
look
at
this.
B
I
went
through
it,
I
mean
I
was
pleased
to
see
that
it
was
written
for
ICP,
so
it
will
just
compile
for
both
Windows
and
Mac
OS.
So,
like
I
was
mostly
concerned
about
that.
But
the
implementations
look
pretty
straightforward
and
simple,
and
if
you
run
openssl
you
can
be
given
Cha-Cha.
So
I
wasn't
too
worried
about
whether
or
not
it's
you
know
considered
real,
so
yeah.
B
A
G
G
It's
a
this
could
overflow
and
it
can't
overflow,
because
there
is
earlier
checks
in
the
code
that
ensure
that
can't
happen.
So
there
was
some
discussion
about
like
how
do
we
actually
prove
that
this
thing
works?
So
it's
not
it's
one
of
those
things
like
if
the
off-the-shelf
implementation
of
the
the
algorithm
is
good,
then
it's
not
a
problem
for
us.
G
A
G
He's
written
it
yeah
he's
written
sort
of
a
you
know
like
an
English
proof,
and
he's
tried
to
write
a
an
automated
proof
of
his
because
he's
very
interested
in
making
sure
it's
fine,
which
is
part
of
why
I
like
this
implementation,
because
he's
very
responsive
and
right
communicates
very
clearly
about
it.
So.
G
H
H
G
I
would
like
to
look
more
at
at
accelerated
versions,
particularly
for
like
the
small
arm
processes,
which
is
still
it's
still.
It's
still
crap
on.
Even
in
software,
it's
just
less
crap
than
IES,
but
if
I
could
get
an
accelerated
version
there,
but
I
thought
yeah
having
the
structure
in
place
first
and
then
extend
further,
but
they
definitely
exist.
G
A
I
I
didn't
know
if
there
were
any
additional
questions.
I
know
that,
based
on
the
discussion
so
far,
there
were
some
some
other
questions
stemming
from
it.
I
know,
Alan
had
some,
although
I'm
is
Alan
on
the
call
I
know
there
was,
in
other
words
I
mentioned,
of
possibly
prototyping
it
and
shaking
it
out
and
seeing
okay.
What
actually
happens
you
know
Does
anything,
go
sideways
or
break
anything
or
get
some
unexpected
results
of
a
chain
of
any
potential
change,
but
just
my
my
original
take
on
this
was
I.
A
A
You
know
we
have
to
allocate
space
for
the
for
the
parody
and
the
way
that
we
display
that
is
so
ZFS
is
like
internally.
It's
keeping
track
of
you
know.
Okay,
I
allocated,
you
know
you
asked
for
128k
and
I
had
to
allocate.
You
know
that
times
1.2
amount
of
sectors
to
to
have
space
for
the
parity,
but
the
way
we
want
to
display
it
to
users
is
like
kind
of
sort
of
ignoring
the
parity
right,
so
at
least
like
kind
of
in
the
in
a
lot
of
default
uses.
A
You
know
you
see,
you
know
if
you
add,
like
four
disks
in
a
Grade
Z1,
then
like
one
of
them
is
being
used
for
parity
that
you
can
kind
of
think
of
it.
That
way.
So
you
know,
if
you
have
three
terabytes
on
these
disks,
then
you
show
three
terabytes
available
and
then
you
know,
as
you
use
up
space,
it's
like
we're.
Allocating
space
on
Awkward
disks,
but
then
we're
we're
displaying
a
space
used.
That's
like
assuming
that
you
had
one
disk
of
parity
in
two
disks
and
the
three
disks
of
data.
A
That's
sort
of
the
overall
idea
that
we're
talking
about
here
now
the
way
that
it's
implemented
in
ZFS
we
so
first
of
all
like
blocks,
especially
small
blocks,
can
need
more
parity
relative
to
the
amount
of
data.
So
you
know,
if
you
have
a
lot
of
small
blocks,
then
we're
like
assuming
this
data
to
parity
ratio,
but
that
might
not
be
true
for
your
small
blocks,
and
so
the
space
used
might
be
more
than
what
you
expect.
A
Now
you
can
set
the
record
size
up
to
16
megabytes
and
those
can
be
stored
more
efficiently.
So
you
know
you
might
see
this
like
this
weird
thing
where
you
know
you
have
like
your
or
discs
one
of
them.
One
of
them
is
parody
and
you're,
storing
stuff
with
vertices
16
Meg,
and
actually
you
get
to
store
like
more.
You
don't
get
to
store
three
terabytes
of
data,
but
you
get
to
store
more
than
what
it
said
you
could
right.
It's
like
when
we
calculated
that
ratio.
A
A
I
agree
that
that
is
kind
of
weird
and
confusing,
potentially
and
I
think
it
would
be
reasonable
to
try
to
correct
that
by
changing
the
changing
the
like
best
case
ratio
of
data
to
parity,
to
reflect
the
actual
best
case
now
of
16
Meg
blocks,
or
maybe
a
theoretical
best
case
of
like
it
is
three
to
one
like
you
know,
it
is
exactly
three
to
one
regardless
of
you
know
whatever.
That's
that's
the
absolute
best
case
possible.
A
A
A
You
know.
Obviously
we
already
have
that
issue
when
you,
when
you
have
compression,
when
you
have
you
know
Z
Vols,
which
have
a
default
record
size
of
16k.
So
it's
like
in
the
default
case.
This
is
going
to
be
a
little
bit
more
noticeable,
which
is
like
not
great.
It's
a
downside
but
I
think
it's
a
minor
downside
compared
to
you
know
having
that,
like
big
ratio,
reflect
kind
of
a
best
case
scenario
rather
than
have
rather
than
having
people
get
confused
about
like.
A
I
Do
I
do
have
a
note
on
that,
and
that
is
where
what
you
were
just
describing,
where
the
user
might
notice
some
additional
difference.
They
would
only
notice
that
change
if
they
were
using
a
sub-optimal
geometry
before,
in
other
words,
if
they
had
a
raid
Z
that
only
had
seven
data
disks
as
an
example
right.
I
So
that's
obviously
sub-optimal
for
storing
one
128k
Stripes
right,
so
that
configuration
is
one
of
those
where
you
would
see
a
few
percent
additional
taken
off
of
just
the
you
know:
data
versus
parity,
whatever
that
percentage
would
be
purely
right
so
that
same
use
case.
If
that
user
had
eight
data
disks.
Before
and
after
this
change,
they
see
no
difference
in
in
that
pool
because
they
didn't
have
any
additional
tact
on
due
to
the
due
to
the
padding
for
128k,
even
in
the
former
case
right.
I
So
this
really
only
fixes
it
for
those
that
end
up
in
the
weird
you
know
these
128ks
don't
fit
properly,
so
we
were
taking
some
extra
off
right
and
then
that
was
the
biggest
observation
or
the
thing.
The
biggest
thing.
That
sort
of
smacks
you
in
the
head.
From
being
on
the
wrong
side
of
that
is
yes,
those
larger
records
all
appear
much
more.
You
know
they
appear
smaller
than
than
There's
Hope
supposed
to
be
right
than
they
actually
are
yeah.
So
whenever
that
number
goes
negative,
that's
where
it
just
gets
really
confusing.
G
I
I
spent
I
spent
a
good
week
trying
to
even
get
to
the
bottom
of.
Why?
Why
are
these?
These
files
are
initially
I
thought
16,
Meg
record
size
was
leading
to
amazing
compression.
That's
what
originally
got
me
here
was
like
wow.
Look
at
how
much
better
this
is
I'm
going
to
do
this
on
everything,
but
then
in
reality,
I
started,
checking
zdb
and
realizing.
No.
That
file
only
has
like
two
compressed
blocks
out
of
a
million,
so
this
this
file
is
really
not
compressed,
but
it
actually
shows
as
if
it
was
eight
percent
smaller.
A
I
I
A
Yeah
so
I
think
the
the
first
question
for
the
the
group
is
like
does
that
seem
like
a
better
semantic
than
what
we
have
now
and
then
the
second
question
is
going
to
be
like
who
who
is
going
to
implement
this
and
how,
which
you
know
that
might
have
to
wait
for
a
later
meeting,
but
first
one
we
see
what
thoughts
other
folks
have
about
changing
that
semantic
kind
of
you
know
as
a
principal
going
forward.
We
don't
know
exactly
how
that's
going
to
take
effect.
Maybe
it
won't
affect
existing
pools.
A
Maybe
it
only
affect
new
pools
or
whatever,
but
like
as
a
principal,
you
know.
Should
we
change
that
change
the
way
that
ratio
is
calculated
to
reflect
more
of
an
actual
best
case
scenario,
now
a
record
size,
16
Megs,
even
though
the
default
record
size
is
going
to
remain
at
128k
for
the
time
being,.
I
I
had
I
had
looked
through
some
of
the
code
again
I'm.
Not.
This
is
really
my
first
diving
through
the
code
base
just
over
this
issue.
I've
only
done
light
dabbling
in
the
past,
but
in
some
talking,
or
at
least
chatting
with
Alan
earlier
and
my
own.
Looking
through
the
code
like
it's
anything
above
trying
to
make
it,
the
revision
only
take
place
for
New
Pools
turns
into
major
surgery
very
quickly
right,
you
have
you
have
one
one
form
of
change:
yeah.
I
There
were
two
separate
proposals
that
I
had
in
there
and
then,
due
to
some
other
concerns
from
that,
Alan
had
led
me
down
a
thought,
hole
of
well
what
if
you
make
the
default
high
so
that
you're
covered-
and
you
don't
end
up
with
the
weird
you
know
negative
percentage
issue
right.
However,
what?
If
you,
what?
I
If
you,
if,
if
a
technically
inclined
user
knew
hey,
this
pool
is
just
for
Z
Vols.
Why
can't
I
just
set
it
to
what
would
correlate
with
16k
if
I
know
that
all
the
Z
Vols
are
16k
that
way,
I've
that
that
pool
will
always
have
an
accurate
free
space
recording
reporting,
unless,
of
course,
you
start
filling
16
Meg
records
or
something
on
there,
then
all
bets
are
off
again
right,
but
that
would
still
be.
I
A
J
I
definitely
have
concerns
that
changing
it
up
will
just
mean
that
the
estimates
for
anything
with
small
blocks
will
get
much
worse
and
if
that
leads
to
people
running
out
of
space
a
lot
sooner
than
they
thought
you
know.
If
Z
pull
this
says
you're
going
to
have
this
much
space,
and
then
you
start
writing
it
and
and
that
space
goes
down
at
three
times
the
rate
you
were
expecting.
That'll
seem
weird
and
I
think
that
having.
J
A
J
A
I
think
that,
like
the
concern
about
being
off
by
3x,
is,
is
valid
and
not
addressed
and
not
addressed
by
this
change
and
not
made
substantially
worse
by
by
this
idea,
yeah,
so
that
that's
kind
of
why
I
feel
like
it
would
be.
Okay,
I
also
am
like
hey.
You
get
some
extra
free
space
like.
Why
are
you
complaining,
but
from
a
like
understandability
point
of
view,
I
think
it
does
make
sense.
You
know,
and
that
was
the
original
intent
was
to
give
you
like
a
best
case
ratio.
I
Right
like
like
when,
when
Matt
came
up
with
that
chart,
that
was
in
his
blog,
the
behavior
was
not
actually
matching
the
chart
in
the
blog
right.
If
you,
if
you
change
it
to
closer
to
either
Infinity
effectively
like
it
goes
away
or
16
Meg,
those
numbers
get
a
lot
closer
to
the
table
in
in
your
blog.
I
A
I
No
yeah
I'm
not
saying
that
the
amount
of
space
actually
allocated
is
incorrect
in
the
blog
that
math
all
checks
out.
What
I'm
saying
is
that
if
somebody
were
to
look
at
that
math
and
go
okay,
I'm
gonna
do
I'm
going
to
pick
this
place,
because
this
is
my
use
case.
This
is
where
I
fit
so
I'm
going
to
make
my
array
based
on
that
information,
then
their
free
space
that
they
get
right
after
they
make.
A
I
C
One
more
wrinkle
I
just
throw
out
there
as
well.
This
is
true
for
raid
z.
You
can
be
quite
a
bit
farther
off
with
the
d-raid
configurations
because
they
do
add
significantly
more
padding.
So
you
know
it
might
not
be
10,
it
might
be
20
or
30
percent
you're
off.
If
you
pick
a
really
unfortunate
geometry
with
really
wide
stripes
and.
I
C
A
A
I
A
Thing
so
I'm
not
sure
the
the
d-rate
math
is
much
less
complicated.
It's
just
like
you
know.
When
you
configure
d-rade,
you
configure
the
stripe
width
right
you're,
like
I
I'm,
having
seven
wide
like
it's
part
of
the
it's
part
of
the
configuration
of
how
many
disks
are
in
the
stripe,
and
so
you
know
the
we're
allocating
in
stripe
width
times,
sector,
size,
increments.
That's
it
right.
I
A
A
I
A
I
A
E
I
A
I
A
I
I
Oh
I'm
not
arguing
that's
common
at
all,
I'm
saying
eventually,
it'll
probably
start
to
happen
with
larger.
You
know
with
ssds
moving
to
a
larger
physical
sector
sizes-
and
you
know,
I
mean
I
work
at
an
SSD
company.
It's
not
inconceivable
to
get
to
an
a
shift
of
15.,
soon
right,
so
you're
going
to
start
to
get
to
the
point
where
a
reasonably
reasonable
with
pool
that's
not
a
obscenely
wide
is
going
to
run
into
this
issue,
and
then
you
know
some.
It
would
need
to
be
addressed
somehow
at
that
point
right.
So.
A
C
I
think
I
think
that
makes
good
sense
and
it's
definitely
encouraged
usage
model,
and
it
you
know,
helps
with
some
of
these
worst
case
predictions
at
the
same
time
like
if
you're,
actually
using
d-raid
and
not
increasing
the
record
size
and
we're
making
these
very
optimistic
predictions
for
you
could
be
surprised
when
you
build
your
pool
and
it
only
you
know,
takes
half
the
capacity.
You
thought
it
would
right.
So
at
the
moment,
it's
kind
of
nice
in
that
we're
under
promising
and
over
delivering
I.
Think
it's
probably
the
gallon
saying.
C
J
I
And
the
percentage
is
on
the
worst
side,
even
currently
go
far
deeper
than
the
percentages
on
the
opposite
side.
Those
negative
values
when
your
records
are
more
larger
right,
usually
that's
just
a
few
percent.
The
other
way,
it's
just
that
those
few
percent
are
really
head.
Scratchers
right.
It's
like
this.
This
file
should
not
be
smaller.
How
can
this
be
smaller?
It's
not
compressed,
but
it
looks
smaller
right.
A
I
I
A
I
J
I
need
to
do
you
enjoy
it
more.
My
question
is:
how
much
of
the
deflated
numbers
are
we
actually
storing
on
disk?
Like
is
the
in
the
accounting,
and
why
would
we
ever
store
that
versus
you
know
reality
of
how
much
space
it
took
and
then
only
have
the
free
space
be
there's
a
calculation
where
we'd
be
able
to
change
it
on
the
fly
without
it
messing
up
all
the
accounting
on
on
disk.
A
J
A
But
I
imagine
it
has
to
do
with
the
fact
that,
like
the
a
pool
can
be
comprised
of
multiple
top
level
videos
which
each
have
their
own
deflate
ratio.
So
when
you
have
a
piece
of
accounting
that
combines
the
space
from
multiple
V
devs
like
say
the
space
used
by
a
file
or
the
space
used
by
a
data
set,
then
you
know
there's
no
real
way
to
combine
those.
A
I
I
A
D
Yes,
that's
my
pull
request
in
my
recent
deep
dive
into
Arc.
Among
the
other
things,
I
touched,
I
went
one
more
point
which
is
archiviction
which
I
found
to
be
obsolete
for
many
years,
because
some
of
algorithms
there
actually
go
predates
abdr
and
they
are
clearly
broken
they're
doing
nothing
Arc
the
court
attempts
to
evict
unevictable
blocks,
but
practice
you
know
truth-
is
that
those
blocks
are
really
not
evictable
they're,
not
even
visible
to
the
eviction
code.
It's
just
that
code.
Do
nothing
and
I
tried
to
try
to
clean
those.
D
I
also
went
deeper
and
tried
to
look
on
long-standing
idea
of
making
Arc
balance
between
data
and
metadata
natively
instead
of
series
of
dirty
hacks
half
broken.
We
we
have
now,
for
example,
right
now
we
have
ghost
state
eviction
which
always
first
week,
data
and
then
only
started
reaching
metadata
which
give
us
by
Design
like
broken
balance
between
ghosts
and
then
broken
balance
between
data
and
metadata.
D
So
I
clearly
wiped
out
all
of
that
code
and
written
pretty
small
couple
of
functions
from
scratch,
implementing
just
a
balance
between
four
different
states
like
datum,
adverse
metadata
and
Mr.
A
few
formative
data
practically
a
quadrant,
so
like
I'd,
like
people
to
take
a
look
on
that
code,
actually
most
of
it
most
of
the
patch,
it
doesn't
looks
really
scary.
D
It's
mostly
mechanical
addition
to
separately
account
for
data
and
metadata,
that's
required
from
us,
so
changes
are
pretty
material
and
the
only
couple
functions
which
are
material
is
architect
and
one
functions.
It's
it
calls
from
inside.
It's
literally
two
pages
of
code,
that's
a
dramatically
different,
but
it
allows
to
remove
so
many
dirty
code
from
R
from
the
GFS
from
The
Arc
eviction
that
I'd
really
like
it
to
be
reviewed.
I'm,
not
saying
that
balance
right
now
is
perfect
in
a
question
of
coefficients
what
should
be
balanced
between
data
and
metadata?
D
What
should
be
rates
of
like
adjustment
with
database
like
different
states,
moving
up
and
down
data
with
the
data,
or
even,
if
you
remember
some,
are
you
some
of
them
were
just
taken:
semi
randomly,
but
I
tested
it.
It's
logic
is
working,
but
some
specific
tuning
May
get
some
tasting
or
for
better
ideas,
but
I'd
like
people
to
to
invite
people
to
take
a
look
on
the
logic
I
implemented
there,
or
is
there
any
assaults?
Opinions
about
that
as
I
thought?
It's
like
two
pages
of
code,
which
is
really
a
worse
review.
D
Exactly
I
don't
use
the
same
mechanism
of
ghost
States
I
just
introduced
that
are
now
practically.
We
always
had
forgot
States,
it's
just
we're
not
widely
announced
and,
as
I
told
they
were
not
really
properly
handled.
Eviction
was
broken
between
data
and
metadata
goes
States,
so
I
really
formalized
four
different
states
daytime
a
few
daytime
or
you
go
a
metadata
mru
and
the
metadata
mfu
like
it's
really
four
different
states.
You
separated
accounts
and
separately
separate
everything.
D
It
could
be
a
miss
because,
like
those
hits
may
be
irrelevant,
if
other
states
also
require
some
memory
so
to
properly
handle
that
it
will
require
much
more
States
like
it's
like
okay,
this
heat
was
very
close
to
recently.
That
was
far
as
it
was
far
much
more
complicated
Mass.
So
so
I
try
to
take
something
in
between
so
sometimes
like,
maybe
hit
75
percent
of
Arc
in
the
head
will
still
be
a
hit.
But
if
you
go
out
on
80
or
about
it
will
be
already
missed.
J
Yeah
I
had
a
question
for
this
looking
at
a
customer
workload
recently,
and
they
wanted
most
that
are
to
mostly
be
metadata
and
currently
with
the
tunables
they
have.
All
they
can
do
is
limit.
What
percent
would
be
metadata,
but
they
can't
actually
limit
what
percent
would
be
data
with
this
change?
Can
you
control
the
maximum
size
of
like
the
the
data
mru.
D
D
That
means
that
as
much
as
you
have
Arc
like
most
of
most
of
it
will
be
metadata,
data
will
be
on
very
minimal
scale
like
that
right
now,
I'm
not
no
longer
measuring
one
of
my
chains.
There
I'm
no
longer
measuring
balances
in
like
bytes
between
a
light
bulbs
between
mrem
a
few
before,
but
now
a
parasitically
measures
them
in
percents.
Well,
fractional
numbers,
yes,
32
30
fractional
numbers,
so
it
should
be
trivial
to
introduce
limit
to
say.
Okay,
we
will
balance
between
data
metadata,
never
less
than
x,
never
higher
than
y.
I
D
I
D
A
Yeah
I
think
the
tricky
part
is
understanding
like
the
dynamic
behavior
of
the
system.
Given
the
code
right
yeah
like
how
do
how
do
things
actually
end
up,
balancing
and
and
making
sure
that
we
aren't
introducing
other
bad
behaviors,
where
you
know
you
get
stuck
with
barely
any
you
know
of
one
of
those
four
types
of
cash
and
then
not
be
able
to
recover
it.
D
Well,
generally,
if
one
case
is
huge,
it
means
others.
Other
states
will
have
huge
ghosts
in
those
ghosts.
They
will
critically
recover.
I
even
I
introduced
the
which
slows
down
like
if
States
going
too
too
low.
It's
actually
like
the
reduction
is
slowing
down
it's
very
difficult,
to
get
to
say
in
states
to
zero
like
after
20
to
15.
It
will
get
really
slow.