►
From YouTube: 2020-01-23 :: Ceph Performance Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
let's
get
going
be,
the
people
from
core
will
show
up
soon,
ish
all
right
new
PRS
this
week.
So
as
a
result
of
our
meeting
last
week,
a
couple
of
chairs
landed
for
doing
PG
auto-scaling
for
PG
auto-scaling
changes,
one
from
Nihad
to
change
the
PG
numb
to
default
teaching
them
to
32
and
the
men
as
well.
A
A
A
A
Let's
see
only
one
PR
this
week,
performance
PR
this
week
close
that
I
could
see
just
a
dot
change
for
OS
diamond
PG
log
entries,
that's
another
one
that
came
out
of
discussion
from
last
week.
A
couple
of
PRS
got
updated
chief,
who
reviewed
this
one
for
splitting
read
IO.
If
the
IO
size
is
at
large
or
NDB
device,
I'm
not
totally
sure,
with
the
what
the
effect
of
that
will
be,
but
theoretically,
hopefully,
they've
tested
it
as
good.
A
Let's
see,
Adams
objection,
triumphant
PR
it
originally.
He
failed
test,
but
it
looks
like
it
maybe
was
due
to
something
else
not
relate
to
his
PR
versus
back
in
testing
again
looking
forward
to
see
they're
seeing
the
results
of
that.
Hopefully
it
means
we
can
merge
soon,
rgw
the
filtering
logic
to
seal
us
that
Erica
added
it
looks
like
that
did
pass
QA
but
needs
rebase
now
so
that
will
need
to
be
rebased.
I
don't
know
if
it
will
need
to
go
back
through
testing
again
or
not,
but
that's
good.
A
Related
to
that,
hopefully,
we
can
figure
out
if
we
can
move
some
of
the
things
that
we
need
to
filter
on
out
of
the
data
structure
there
so
that
we
don't
actually
have
to
decode
the
entire
thing
in
the
CLS,
but
instead
can
just
decode
whatever
we're
filtering,
then
kind
of
reduce
some
of
that
overhead.
That
was
pretty
sitting
prior
to
this
PR.
So
it's
not
like
it
had
anything
new.
A
The
objection
sustained
that
got
updated
and
rebase
to
look
like
and
then
other
atoms
blue,
starting
work
that
got
some
new
changes
based
on
a
short
review
that
we
did
is
either
last
week
or
the
week
before.
I
think
he's
working
on
just
making
simplifying
to
hold
things
there
before
we
before
we
merged
that,
so
that
was
about
it
for
this
week.
So
far,
oh
and
perfect
timing,
it
looks
like
some
of
the
people
from
chorus
trying
to
show
up
here.
A
A
B
B
In
octopus,
we
currently
have
min
alaq
size
set
to
4k,
and
this
works
around
the
issue,
but
at
the
same
time
we
are
still
thinking
about
my
bachelor
version,
this
back
to
16
or
even
okay,
as
since
large
large
allocation
sizes,
a
bit
of
from
performance
point
of
view,
and
hence
we
need
by
some
attention
to
this
space.
Simplification
for
every
recorded
post
I
have
just
found.
B
Tom
use
patterns,
I'd
have
multiple
allocations,
birth,
o-64,
ke
blob
and
hence
allocations
special
players.
Space
simplification
might
be
pretty
high,
so
I
provided
some
that
is
simple
and
straightforward
scenario
to
to
reproduce
this.
It's
quite
efficient,
but
more
realistic
scenarios
can
suffer
from
the
same
here
as
well,
like
I,
feel
the
RVD
image
and
then
partially
right
some
okay
extent.
Then
you'll
get
on
each,
maybe
not
on
each,
but
on
each
four
key
of
the
right,
which
takes
its
own
64k
range.
You'll
get
another
location
without
previous
extent,
relief.
A
D
D
D
B
B
B
D
Only
the
only
question
is
like
what
do
we
do
with
a
spinner
and
also
yes?
So
if
it's
you
see,
we
also
always
so
we
it's
a
spinner
and
replicated
that's
the
only
question
right
and
so
there
it
really
seems
like
this
is
going
to
be
it.
This
is
a
pretty
narrow
case,
because
if
you
get
a
big
right,
then
we're
gonna
do
a
big
allocation
right.
There's,
nothing
really
to
do
I.
Think
the
only
question
is:
what
do
we
do
if
we
get
a
small
right
on
a
hard
disk
replicated
pool.
B
B
B
Because
we
have
some
I
recall,
an
unused
bitmap
probably
depends
on
that
and
maybe
something's
something
else.
So
if
you
look
at
this
PR
with
flexible
monoxide,
selection
I
need
to
provide,
but
I
need
to
persist
with
alt
apply
to
this
object
and
I
need
to
provide
min
alaq
size
to
number
of
functions.
Yes,.
D
And
well,
I
guess
I'm,
not
thinking
about
this
in
terms
of
metallic
size,
because
metallic
size
by
definition,
is
the
allocation
unit,
and
that
is
always
that
is
4k
right,
there's
not
so
much
metallic
a
metallic
size.
It's
it's!
How
big
we
allocate
our
blobs,
it's
like
how
big
do
we
allocate?
That's?
Actually
the
question
not
middle
like
size
right.
So
if
we
get
a
large
right
for
example,
then
we'll
do
a
large
allocation.
D
The
question
is:
how
big
do
we
allocate
a
small
right
and
by
default,
the
current
behavior
is
that
we
always
allocate
the
smallest
allocation,
the
smallest
multiple
of
metallic
size,
that's
sufficient
for
a
new
right,
that's
the
current
behavior,
and
that's
that's!
Basically
the
crux
of
it:
that's
that's
the
thing
that
we
might
need
to
change,
because
if
you
have,
if
so,
if
you
have-
let's
say
you,
let's
say
you
pre-fill
an
RB
d
image,
and
so
it
has
a
bunch
of
big
allocations
and
you
just
a
small
right
comes
along.
D
It's
going
to
write
into
that
into
that
same,
it's
gonna!
Do
it
over
right
right,
though,
there's
no
allocation
anyway,
and
it's
fine.
So
the
only
question
is:
what
happens
if
we
get
a
small,
random
I/o
and
a
part
of
the
inch
that
hasn't
been
written
yet,
do
we
allocate
a
small
allocation
or
do
we
do
a
large
allocation
and
write
only
a
small
piece
of
it
and
set
it
to
be
unused.
B
D
B
B
D
Guess
I
think
I
might
be
misunderstanding,
something
I'm
not
showing
what
is
complicated
because
I.
My
understanding
is.
This
is
how
it
blue
stores
worked
from
day.
One
right,
a
blob
can
be
big.
It
can
be
small,
there's
like
a
different
right
for
do
you
write
big
and
it
has
to
decide
how
big
the
blob
should
be
allocated.
There's
a
maximum
size,
though,
that
they
aren't
extremely
big
but
like
they're,
always
different
sizes.
B
D
B
D
Not
just
technically
possible
but
like
probably
true
of
almost
every
object
in
the
store
that
has
had
non-trivial
I/o
settings,
because
if
you
have
that
you
write
say
metallic
size
in
64k,
you
do
a
384
k
right
and
then
you
do.
128
K
right!
You're
gonna
have
two
blobs
that
are
totally
different
sizes.
And
then
you
do
a
4k
right
and
it's
gonna
do
another
64
K
blob
and
that's
mostly
empty,
but
has
a
that's
a
fork.
A
little
pot
filled
in
let's
unused
bits
set
and
all
that
stuff.
If
you.
D
B
D
D
Can
we
set
that
pull
request
aside
for
now
and
just
talk
about
what
currently
happens
and
what
we
want
to
change
because
I
don't
want
to?
Let's
just
let's
just
talk
about
first,
what
the
code
does
and
what
behavior
we
actually
want
to
change
and
then
talk
about
possible
ways
that
we
can
get
that.
But
let's.
A
B
Well,
the
second
use
case
is
well
it's
similar
to
our
BG,
but
some
general
purpose
pool
which
in
plenty
of
small
objects-
and
this
differs
from
our
GW
case
in
in
a
way
that
we
can't
control
if
objects
are
written
in
a
single
shot
or
so
in
a
GW.
We
can
say
that
small
objects
are
eaten
in
single
shot,
and
this
simplifies
the
handle
in
general
purpose
pool.
B
D
That's
theta
the
shared
plots,
not
things
writable,
it's
the
new
allocation.
Okay.
So
if
we,
if
we
basically
talk
about
current
master,
we
changed
metallic
size
to
4k.
So
all
three
of
those
issues
are
solved
right.
Well,
rjw
objects
are
small
and
small
objects.
Written
pieces
are
still
small
and
the
easy
flow
overhead
is
mostly
gone
because
the
allocation
sides-
at
least
it's
gotten
as
gone
as
it
can
be,
given
that
we
have
to
do
the
cloning
ensured
Bob
dance
well,.
B
D
That's
yeah
I
think
just
cause
it'll
get
for
you,
mostly
a
minor
in
your
node,
but
whatever
I
think.
That's
that's
a
separate
discussion.
So
the
only
real
problem
with
so
I
think
4k
just
setting
metallic
size.
The
4k
solves
like
90%
of
our
problems
right
on
SSD.
Is
we
always
want
4k
on
ratio
code
pools?
We
always
want
4k
or
rgw.
We
always
want
4k.
The
only
problem
is
if
it's
a
hard
disk
and
I'm.
D
A
D
D
Okay,
cuz,
it
seems
like
there's
this
sort
of
their
their
two
categories
of
issues.
Here,
one
category
is
how
big
should
our
allocations
be
like
if
I
get
a
small
right
should
I
do
a
large
allocation
and
right
only
a
small
piece
of
it,
because
that's
gonna
be
better
in
the
long
run
or
do
if
I
get
a
small
right
to
I
write
to
a
small
allocation?
D
That's
one
category
like
how
big
should
I
allocate
and
the
other
category
is
like-
is
the
allocator
just
behaving
well
right,
like
am
I,
if
I
do
a
large
allocation?
Is
it
aligned
so
that
when
I
do
small
locations,
things
are
less
likely
to
fragment,
or
you
know
whatever
it
is
like
I
think
there's
their
stuff
that
could
probably
just
be
or
if
I
do,
a
large
allocation,
and
there
are
both
large
extends,
free
and
small
extends
free.
D
Do
I
return,
the
logics,
tent
or
jury
returned
a
bunch,
a
little
extents
mushed
together
and
that
I
think
it's
just
an
alligator
implementation
question
the
things
that
we
could
good
or
maybe
should
improve.
If
I
don't
know
what
the
current
behavior
is,
but
maybe
that's
that's
like
a
segment,
the
second
category
of
problem
that
makes
sense
I.
D
D
Yeah,
just
because
we're
doing
locations
right
so
that
feels
like
that's
a
that's
the
first
category
of
how
big
should
I
do
my
allocations
because,
like
I,
can
imagine
that
for
ARB
d,
for
instance,
say
it's
a
completely
empty
image.
We
get
a
4k
random
right,
that's
in
some
random
offset
and
the
current
behavior
is
or
K
that's
a
multiple
of
Menelik
size
and
so
I'm
just
going
to
allocate
for
K
and
so
you're
just
going
to
get
a
tiny
allocation.
D
And
then
you
write
randomly
right
before
K
next
to
it
and
you'll
get
another
location
and
so
on,
or
you
could
say
it's
a
4k,
random
right
but
I
know
this
is
a
block
image
and
I
want
to
like
reduce
long-term
fragmentation
and
so
on,
and
so
I'm
actually
going
to
allocate
64
K.
Even
though
I
need
four
K
of
it
right
now,
and
that's
a
decision
that
you
have
to
make
on
that
first
rate
right.
D
D
It
could
also
be
age
all
right,
just
one
sec
mark.
It
could
also
be
that
there's
a
for
an
issue.
It
could
be
that
there's
a
different
issue
right.
It
could
be
that
I
do
decide
to
allocate
64
K,
but
that
64
K
allocation
I
do
isn't
aligned
to
a
64,
K
boundary.
It's
like
shifted
and
as
a
result,
when
I
do
you
know
a
million
$80
locations
and
releases,
and
so
on.
I
get
some
fragmentation,
even
though
most
of
my
allocations
are
big.
D
D
But
I
think
that's
not
really
what
we're
worried
about
right
now.
I
mean
we
fly
one
I
think
about
that
later,
but
I
think
the
real
question
right
now
is
just
how
big
do
we
allocate
I'm
guessing?
Wouldn't
we
get
a
smaller
and
as
Ennis,
and
it's
really
only
for
our
buddy
and
Seth
FS
on
hard
disks
or
replicated
pools
like
that's
the
only
that's
the
only
time
it
matters
the
rest
of
time.
We
always
want
to
just
do
the
smallest
allocation.
We
can.
A
D
Yeah
yeah,
yeah
and
I
was
actually
say
that
in
the
case
of
RVD
like
we
basically
always
want
to
do
slightly
larger
allocations,
because
we
don't
have
this
sort
of
like
small
file
issue
like
it's
a
block
device,
an
X
of
s
is
gonna
back
or
not.
Pack
lot
put
like
I
think
we
shouldn't
get
better
issues
without
that
we
just
need
to.
We
should
assume
it's
sort
of
a
a
sparsely
but
coarsely
allocated
chunk
of
space.
Then
file
system
is
gonna.
D
Gonna
do
yeah,
though
I
mean
even
something
as
simple
as
if
it's
an
RVD
pool
and
its
rotational
and
its
replicated,
then
we
should
make
them
in
blob
size,
64
K,
instead
of
whatever
it
is
right
now,
Menelik
size
and
for
our
buddy
I
think
that
would
basically
solves
well.
Okay.
So
here's
here's
actually
the
question:
we
keep
talking
about
how
it's
slower
the
metalic
size
made
something
slower
what
actually
was
tested
and
what
actually
was
slower.
What
was.
B
D
A
C
C
A
D
B
D
D
D
D
Rights
get
faster
but
reset
floor
and
that's
just
cuz
they're
smaller,
that's
right
now,
but
this
here
is
probably
with
a
small
rights
where
we
would
want
to
do
a
larger
allocation,
even
though
we
don't
have
to
our
every
D
think
that
what
I
was
just
talking
about
that
sort
of
makes
sense.
What
at
this
large
right
do
we
have
any
idea?
Why
that's
the
case
like?
Why
would
why
would
a
large
right
be
like
half
as
fast
like
less
than
half
as
fast.
D
D
A
G
D
So
it
seems
like
that's.
This
is
the
thing
that
we
need
to
understand
like
why
what
is
actually
going
on
cuz?
Maybe
it
from
this
like
just
guessing.
It
seems
like
it's,
maybe
a
problem
with
the
implementation
of
the
allocator
I
blue
stars,
probably
asking
for
big
blobs
and
the
allocator
is
giving
a
little
lens
a
bunch
of
little
ones,
probably
just
something
that
the
allocator
should
do
different.
B
D
B
D
Mean
I
would
suggest
that
we
first
just
rerun
these
tests
and
then
look
at
what's
actually
happening
and
try
to
understand
what
that
what
the
change
behavior
is.
If
it's,
if,
in
fact
it
is
just
getting
smaller
locations
and
we
actually
understand
at
least
we
understand
why
we
can
figure
out
how
to
make
the
allocator
get
bigger,
bigger
things.
D
Just
or
just
look
at
the
log
and
see
what
have
you,
how
big
the
action
requests
are
and
how
big
the
results
are
sure
than
that,
and
then
it
could
compare
it
for
the
to
forgive
and
just
look
at
the
a
new
case
that
that
sounds
like
problem
number
one
and
then
problem
number
two
is:
if
we
want
to
do
something
about
the
small
right
behavior,
where
we're
basically
trading
right
performance
for
read
performance,
and
that
would
be
more
subtle
thing.
We're
not
here,
I
guess
here.
A
C
A
D
Be
in
it-
and
maybe
that's
just
because
that's
that
same
allocator
behavior,
that's
breaking
our
large
rights
yep
and
that
actually
makes
sense.
Because
if
you're
dealing
like
a
bunch,
a
mix
of
4k
iOS
and
like
128
K
is
then
you're
going
to
have
a
bunch
of
for
K
holes.
And
then
you
do
128
allocation
and
it's
good.
You
can
give
you
like
a
bunch
of.
D
So,
if
that's
the
case,
then
it
seems
like
there's
basically
one
problem,
possibly
or
wait
mostly
one
problem,
and
that's
just
that
if
there's
a
fragmented
free
space
and
you
ask
for
a
large
allocation,
the
allocator
is
giving
you
little
pieces
that
doesn't
know
how
to
give
you
okay
so
way
back
when
I
got
in
my
four
years
now.
D
Whatever
remember
first
talking
about
this,
when
we're
talking
about
the
bitmap
allocator,
we
had
this
idea
that
there
should
be
hierarchical,
bitmaps
where
there's
the
bitmap
of
the
actual
granular
blocks,
but
then
we
would
also
have
a
coarse-grained
bitmap.
That's
like
I,
don't
know
a
couple,
an
order
of
magnitude,
more
granular,
less
granular.
That
would
either
be
completely
free
or
completely
used
or
whatever,
so
that,
if
you're
doing
large
allocations,
you
could
efficiently
find
those
large
blocks
and
if
you're
doing
more
allocations
and
you'd
end
up
going
down
to
the
is
that
the
data
over?
F
F
B
C
B
B
D
A
If
the
40
min
Alex
is
the
biggest
problem
we
had
with
it
was
was
encode
decode
of
metadata.
It
was
actually
in
all
cases
yeah,
and
that
was
now
we've
improved
everything
to
the
point
where,
on
a
flash
it
looks
like
we
were
often
better
with
a
fork,
a
metallic
size
in
all
cases,
including
small,
where
we
then
don't
have
to
eat
the
threatened
blog
go
read
because
we're
okay.
D
Right
so
I
think
so
we
have
our
line
of
investigation
right.
We
need.
We
want
to
try
the
AVL
allocator,
do
what
happens
and
also
look
at
a
bitmap
one
and
understand
what
the
allocations
look
like
and
see.
If
that
is,
if
we
understand
what
the
core
issue
is,
but
I
think
we
have
a,
we
have
to
figure
out.
We
have
a
decision
point
for
octopus
just
like
both
if
we
want
to
stick
with
the
4k
Alex
eyes
or
if
we
want
to
go
back
to
64.
D
That's
like
I
think
what
we're
basically
trading
is
with
a
64
klx
eyes
and
we've
have
tons
of
space
amp.
The
performance
is
better
at
least
four
large
rights,
whereas
with
the
4k
alex
is
that
we
have
right
now,
then
the
space
overhead
issues
go
away,
but
large
streaming
rights
are
slower,
but
smaller.
D
Bester
yeah
and
mixed
rights,
or
slower
right,
it's
like
only
the
very
small
ayahs
that
go
faster,
exactly
which
is
like
just
any
pesticide
that
does
that
describe
any
work
whatever
like.
Even
though,
like
realistic,
torturous
or
VD
workload.
Isn't
it's
gonna
be
a
mix
right?
It's
gonna
be
a
mix
of
small
and
big.
It's
not
gonna,
be
just
yeah,
probably
unless
you're
doing
something
like
crazy
on
it
right
yeah,
which
basically
means
it's
just
slower
yeah.
If
we
trade
it,
we
trade
space
amp
for
performance,
so.
A
D
B
D
B
B
B
A
D
G
E
C
A
B
C
D
There
was
basically
just
passing
its
setting
than
Alex
eyes
to
4k,
but
it's
requesting
64
K
at
a
time
and
setting
that
flag.
That
says
it
has
to
be
a
continuous
yeah
that
we
were
saying:
okay,
so
that
that
also
I.
Think
that
also
makes
me
nervous
until
we
understand
what
the
alligator
behavior
should
be,
because
that
has
the
risk
of
with
an
age
store
like
just
being
wasting
CPU,
because
it
has
to
do
this.
D
D
Like
it
seems
to
me
if
it
seems
to
me
that
the
most
that,
if
we
want
to
do
something,
the
conservative
thing
would
actually
be
to
for
hard
disks,
create
the
store
with
Menelik
size
of
4k
but
have
a
flag
on
the
allocator
that
says,
you're
required
to
actually
do
64
K,
multiple
allocations
for
the
whole
device,
always
just
so
that
the
disk
format
is
is
the
same.
And
so
when
we
eventually
fixed
this
yeah.
A
D
C
B
C
That's
a
good
question
for
hard
disks
users.
I
would
expect
less
performance
sensitive
than
that,
and
then
it's
basically
I'm
sensitive
for
that
case.
Okay,
the
nice
thing
about
the
our
debut
small
writes,
though,
is
that
we
know
that
the
property
site
is
going
to
be
4k
or
whatever,
whatever
small
size.
It
is.
When
we're
writing
it,
it's
not
gonna
change.
So
if
we
did
have
this
like
this
layout
in
4k
in
oxide
blocks,
I
mean
I
mean
we're
doing
it
immutable
rights.
A
A
G
So
if
I
have,
to
put
it
simply,
I
think
we
are
going
to
improve
things
for
customers
who
are
using
SSD.
We
are
not
changing
anything
for
our
customers
who
are
using
hard
disks.
We
can
live
with
that
as
long
as
we're
saying
that
we're
making
forward
progress
towards
that
in
a
later
release
or
like
even
later
or
octopus,
point
release.
So
as
long
as
we're
not
going
worse
and
fine
with
that.
G
A
G
G
A
G
I'm
just
saying
that
the
worst-case
scenario,
what
we
are,
what
we
are
able
to
do
with
octopus,
is
that
we
go
down
to
for
like
4k
what
we
have
already
done
for
master.
We
just
go
up
for
hard
discs,
which
is
64
K,
which
is
literally
what
we
were
doing
for
the
hard
disks
case.
We
are
not
changing.
Anything
is
what
I'm
trying
to
say
in
future.
We
know
that
it
is
a
problem
and
what
Igor
is
going
to
investigate
will
get
us
to
a
better
solution.
G
A
E
A
C
A
B
C
A
C
Yeah
it's
late
a
couple
weeks,
but
I
have
enough
time
to
make
her
eat
it.
Whatever
come
up
with
the
is
tested
enough
that
we're
confident
in
it
for
octopus,
I.