►
From YouTube: 2019-08-01 :: 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
Alright,
let's
get
started,
though
one
new
PR
this
week
this
is
Neha.
This
is
the
ones
we're
having
a
discussion
about
and
I
think
we're
gonna
try
to
discuss
this
for
our
primary
discussion
topic
this
week,
but
the
the
the
RFC
here
is
to
make
the
blue
FS
Alex
eyes
default
to
be
the
same
as
the
blue
storm
and
Alex
eyes,
and
to
set
that
to
16
K,
which
is
the
current
people,
SSD
metallic,
sighs
and
blue
store,
but
at
least
for
us
T's.
That
would
be
the
what
we
said
for
a
default
idea.
A
I
suspect
we'd
still
set
it
to
64
K
by
default
for
our
hard
drives,
but
we
can
talk
about
that
more
later
on.
So,
let's
see
there's
a
couple
of
PRS
that
closed
this
week.
A
A
Let's
see
the
last
one,
no
and
then
the
second
one
here
that
closed
for
me
was
this
trim
cash
on
ad
that
actually
got
folded
into
the
P.
Above
once,
though,
that
was
just
close,
all
right,
updated,
Eric's,
the
rgw
small
efficiency
gain,
yeah
I
got
put
in
testing.
It
looks
like
so
probably
merged
time
this
week
or
next
week.
A
B
A
B
B
Are
two
branches?
One
is
the
objection
sustained,
which
is
our
rgw
specifically,
the
I
object
is
just
the
object,
ER
and
neo
Rados,
or
even
want
to
call
it
patches.
So
if
someone
doesn't
care
about
rgw,
they
can
just
review
the
I
object.
I'll
have
to
double
check
and
make
sure
that
one
is
up-to-date.
C
B
D
A
A
A
He
also
has
a
PR
on
top
of
it
that
takes
my
work
from
27
and
705
for
avoiding
double
cashing
of
loose
Toro
nodes
and
applying
it
to
his
work.
There.
There
was
a
question
where
I
had
a
question
for
me
last
week
about
whether
or
not
and
of
what's
what's
gonna
happen
in
terms
of
backporting
and
if
we
can
get
the
sharding
work
back
forward
to
nautilus
and
then
this
PR
backporting
to
nautilus,
and
he
raised
the
possibility
of
of
my
PR,
maybe
being
easier
to
back
port.
A
A
E
E
A
F
A
A
Better
utilization
of
the
flash
drives
for
DB
utilization
right
because
by
sharding
we'll
have
lots
of
smaller
level,
1
and
level
2
hierarchies
or
multiple
hierarchies
with
more
level
1
and
level
2
's
versus
like
one
hierarchy
with
the
own
level,
1
level,
2
level,
3,
level
4,
but
but
potentially
Igor's
changes
could
will
make
that
even
better
or
could
still
allow
us
to
get
better
utilization
even
in
the
single
hierarchy.
I'm
sure
every
case.
So
that
might
be
something
for
us
to
think
about.
A
A
A
The
idea
here
is
that
he
really
would
like
to
keep
string
view,
as
have
the
the
interface
that
we
use
for
any
kind
of
dynamic
strings
that
were
keeping
in
the
event
and
I
understand
that
that's
reasonable
and
then
I
think
what
will
maybe
can
move
forward
is
instead
of
the
current
model,
where
we
we
mix,
static
and
dynamic
event,
types
that
are
represented
by
by
strings.
Instead,
we
have
those
events
becomes
static,
but
with
an
optional
dynamic
like
info
field,
or
something
like
that.
A
That,
then,
could
provide
the
same
kind
of
dynamic
information
that
we
sometimes
have
in
the
the
a
preference
that
would
be
optional
and
and
then
could
only
would
only
have
a
performance
impact
when
they're
used
so
I
think.
Hopefully
that
would
give
us
kind
of
the
best
of
all
worlds,
but
but
that
will
just
kind
of
take
a
little
bit
of
a
bigger
change
in
the
app
tracker
than
what
we
have.
Now,
though,
if
there's
that.
A
E
E
E
A
A
A
A
G
That
issue
is
resolved,
but
even
when
there
is
a
situation
that
there
aren't
enough,
the
unit
of
size
that
blue
FS
Alex
eyes
is
currently
which
is
M
1
MB.
If
there
aren't
enough
1,
MB
chunks,
left
or
in
blue
store,
provide
2
blue
FS,
then
we'd
still
run
into
similar
fragmentation
issues.
So
that's
a
kind
of
the
brief
overview
of
what
the
reason
behind
this
PRS.
So
we
now
have
back
ported
bitmap
alligator
and
are
also
making
it
the
default
for
all
versions,
including
Luminos.
G
The
next
step
we
thought
would
be
to
make
both
these
allocation
size
equal.
This
is
kind
of
an
interim
step
before
we
actually
get
rid
of
both
these
different
allocation
sizes,
ideally
in
octopus,
I,
believe
we
want
to
get
rid
of
both
these
sizes
and
we
only
have
just
one
allocation
size
so
that
we
don't
have
this
problem
at
all,
but
for
back
portable
trees
and
for
legacy
releases.
We
want
to
just
come
up
with
this
PR,
which
should
solve
some
of
the
problems
that
we
are
having
in
the
field.
G
So
the
PR,
currently
what
it
does
is.
So
there
are
these
two
configuration
values.
One
is
loose
toward
men
Alex
eyes,
and
it
also
has
two
different
s:
SSD
and
HDD
versions
of
it,
and
then
there
is
another
configuration
which
is
blue,
FS
Alex
eyes
now.
Currently,
both
of
them
are
independent.
Blue
F,
blue
Stormin
Alex
sizes
match
to
figure
out
whether
it's
running
on
an
hottest
core,
SSD
and
figures
out
which
value
it
should
use,
put
them
in
alex
eyes.
G
G
Only
in
the
scenario
when
the
user
does
not
have
a
specific
value
specified
in
7th.
If
chef
cons
has
this
blue
FS
alex
eyes
to
be
zero,
it's
just
going
to
default
to
whatever
boost
oarsmen,
alex
eyes
is,
and
in
case
the
user
wants
to
explicitly
override
that
they
can
still
do
that
by
adding
a
particular
value
in
safe
conf.
The
only
catch
there
is
that
currently,
the
way
the
code
works
and
as
Mark
has
described
earlier,
that
there
are
restrictions
as
to
what
the
lowest
value
of
blue
FS
alex
eyes
can
be.
G
So
the
PR
now
also
has
a
minimum
alex
eyes
that
it
binds
blue
FS
Alex
eyes,
which
is
currently
set
to
16
K,
which
is
the
default
also
for
a
blue
storm
in
Alex
eyes,
though,
if
the
user
ever
tries
to
go
below
that
by
overriding
through
safe
conf,
the
code
will
make
sure
that
we
never
go
below
16
K.
That
is
just
to
handle
that
scenario
and
in
the
legacy
blue
store
code
which
doesn't
handle
lower
than
I.
G
A
Sony
I'm
the
one
that
actually
chosen
16
K
malloc
size.
So
that's
one
of
the
reasons
why
I
have
kind
of
a
strong
opinion
on
this
when
we
decided
that
it
was
very
much
based
on
the
fact
that,
at
the
time,
blue
store
had
a
fair
amount
of
encode
and
decode
overhead
when
putting
data
in
rocks
TV-
and
we
also
just
in
general,
had
enough
metadata
overhead
in
blue
store
that
it
was
at
the
time
quite
a
bit
faster
to
use
a
16
K
metallic
size
with
SSDs
rather
than
a
fork,
a
metallic
size.
A
A
It
was
definitely
a
trade-off,
and
at
the
time
it
was
a
trade-off
that
that
we
wanted
to
make,
because
we
really
wanted
to
showcase
that
blue
store,
wasn't
gonna,
be
slower
than
file
store
or
small,
random
I/o
with
our
BD.
Now
it's
questionable
whether
or
not
we're
actually
significantly
faster,
with
a
16
K
Menelik
size,
rather
than
4k
one
doing
that
those
extra
while
rights
may
actually
be
slower
than
eating
the
extra
metadata
and
encoding
overhead
of
having
the
before
King
and
LX
eyes.
A
How
this
plays
into
having
the
blue,
FS
Alex
eyes
be
the
same
as
the
man
Alex
eyes
have
just
adds
a
more
dimension
to
all
of
this,
because
now
it's
kind
of
a
question
of
well.
Are
you
better
off
potentially
eating
the
space
amplification
of
small
objects
or
you
better
off,
potentially
eating
some
space
amplification
or
having
a
fragmentation
that
you
can't
that
you
can't
really,
you
know
work
around
for
as
far
as
being
able
to
get
more
space
out
of
the
device.
I
don't
know
the
answer
to
that.
A
I
have
a
suspicion
that
there's
probably
some
balancing
point
between
the
two
where
you
have
like
some
one
megabyte
is
definitely
probably
not
the
right
point
to
balance
your
own,
but
whether
or
not
having
the
Menelik
size
and
the
blue
FS
Elek
size
be
exactly
the
same
you're
not
eating
any
space
application
space
amplification
that
way
or
if
you
are
better
off
kind
of
allowing
for
a
small
metallic
size
or
smaller
metallic
size
and
a
fairly
small
blip,
has
a
log
size
but
still
have
a
little
bit
of
space.
Amplification
due
to
fragmentation.
A
G
A
G
That
option
that
option
so,
okay,
that
option
only
holds
true
till
16
K,
the
16
K,
blue
FS
metallic
size
and
sorry
blue
FS,
Alex
eyes
and
blue
Stoneman.
Alex
eyes
are
one
entity.
Once
you
hit
the
16
K
mark,
they
become
independent
identities.
I
we
then
say
that
we
now
again
go
back
to
our
previous
way
of
thinking,
and
we
say
that
we
are
going
to
cap
blue
FS
alex
eyes
at
16k,
no
matter
what,
but
you
can
go
down
with
your
blue
storm
in
alex
eyes
to
whatever
the
hell
you
want.
G
You
know
you
can
even
go
back
to
4
K
or
16
K
or
whatever.
So
I
can't
see
that
we
are
binding.
People
I,
just
I,
agree
that
the
best
the
ideal
case
would
be
for
people
to
be
able
to
set
it
to
whatever
they
like.
But
since
the
fact
is
for
previous
versions
of
the
court,
it's
not
possible
to
do
that
immediately
so
until
unless
we
have
that
solution
place,
I,
don't
see
that
this
is
going
to
necessarily
be
a
hurry
for
them.
It's
just
going
to
be
better.
Yes,.
A
A
So
the
the
only
then
for
me,
the
the
only
concern
would
be
whether
or
not
you
know
the
performance
hit
with
a
16-page
blue
FSL
excises
is,
you
know,
is
worth
it.
You
know,
we've
got
some
test
results.
There
we've
some
of
our
other
changes
like
the
the
cash
refactor
and
also
the
the
the
thread
count
for
rocks
TV
compaction.
A
G
C
B
G
A
A
So,
okay!
Yes,
that
that
would
be
the
one
that
might
have
the
biggest
impact,
because
with
the
Blue
Hose
Alec
size
being
said,
small
is,
it
seems
to
be
all
Memphis
hit
the
hardest,
though,
and
that's
what
the
increasing
or
actually
be
compaction
turns
hopes
the
most
so
that
that
would
be
a
potentially
a
good
weight
off
Senate
the
the
hit
from
it.
A
And,
and
maybe
also
I
just
started
looking
at
it,
but
I
get
more
work
to
do.
Certainly
we
can
look
at
whether
or
not
there's
anything
else
we
can
do
in
the
OSD
to
to
help
minimize
the
impact
of
the
smaller
blue
FS
allocation
size.
Maybe
there's
just
a
bit
of
code
in
there
that
you
know
we
can.
We
can
tweak
a
little
bit
to
to
at
least
provide
some
improvement.
F
Yeah,
like
you
were
saying
about
the
fragmentation
I
mean
from
workers
faces
coming
from
man,
better
they'd
overhead
from
the
band
size
being
16
K
for
small
objects
thankful
further
further
than
the
future.
It's
worth
looking,
yes,
like
you
said
for
kami,
oxidizer
boost
or
again,
and
because
we
are
seeing
lots
of
like
with
with
our
W,
especially
very
small
object
workloads
or
they
historian.
Okay,
so
sighs!
It's
like
2
to
8
k.
A
A
Yeah
I
the
last
time
I
looked
at
it.
It
was
almost
break
even
with
16
K
Menelik
size,
which
was
a
big
improvement
over
where
we
were
like
two
years
ago.
Interesting
so
so
all
may
be
well
do
as
as
I'm
doing
these
this
other
testing
and
and
profiling
to
see.
If
there's
anything,
we
can
do
to
make
the
blue
fest
minal
exciting
blue
FS
Alex
eyes,
you
know
less
impactful
may
be
simultaneously
here.
F
A
Think
we
would
write
because
Neha's
PR
is
going
to
if
I
understand
it
right.
It
will
as
soon
as
you
drop
below
16
K
it'll.
Keep
the
blue,
though
they'll
be
different.
It'll
keep
the
blue
FS
Alex
eyes
at
16k,
but
the
loose
or
metallic
size
would
be
4.
K,
then,
is
that
right,
knee
yeah.
That
sounds
right.
G
A
A
A
We
didn't
want
to
look
that
way,
so
we
we
were
faster
if
we
had
a
16
K
Menelik
size,
but
a
lot
of
that
was
because
at
the
time
we
still
had
I
wasn't
blue
store
new
store,
even
at
that
point,
I
think
it
was
blue
store,
but
it
was
our
encoding
overhead
was
was
high
enough
at
that
point,
plus
most
random
other
stuff,
but
that,
having
the
increased
amount
of
metadata,
really
kind
of
bottleneck,
the
KB
sync
thread
the
point
where
it
was
slow.
A
Now
we
see
the
KB
sync
thread,
often
not
even
not
even
pegging,
on
random
race,
which
is
is
kind
of
impressive,
since
we
haven't
I,
don't
think
we've
explicitly
focused
on
that,
but
just
all
the
random
stuff
people
have
been
doing
for
the
last
few
years
seems
to
have
at
least
on
the
in
certain
notes
made.
It
so
that
we
we
tend
to
bottle
and
other
stuff
before
the
KT
sync
thread.
A
It's
still
up
there
still
like
in
a
lot
of
my
tests,
is
still
like.
You
know,
70
to
80
percent
of
the
time
spent
doing
work,
and
you
know
the
times
done
just
waiting,
but
but
still
you
know,
it
is
probably
time
to
retest,
maybe
with
my
double
caching
PR
and
possibly
with
the
cash
spinning
applied,
but
even
without
those
we
could
still
look
at
it.
A
E
E
F
A
So
we
would,
we
would
set
the
blue
of
us
Alec
sized
to
the
existing
metallic
size
and
as
long
as
it's
created
greater
than
equal
to
16,
K,
yeah
yeah,
so
so
anything
16,
K
or
higher.
Depending
on
what
that
sets
you
and-
and
that
will
be.
We
think
that
will
be
okay
on
existing
OS
T's
that
have
already
been
using
a
one
megabyte
blue
FS,
Alex
eyes,
I.
G
Think
so,
because
I
think
Adam
has
done
some
experiments
with
existing
setups
and
he
went
down
to
I
think
256.
Okay
and
he
didn't
see
any
issues,
though
I
don't
think,
but
we
are
doing,
are
lots
of
testing
to
also
make
sure
it
doesn't
cause
any
other
issues.
So
if
there
are
problems,
we
should
be
able
to
find
that
out.
A
All
right
well
sounds
good,
so
next
week
it's
possible,
we
are
going
to
get
Sam
just
in
he
indicated
that
he
might
be
have
some.
You
might
have
some
data
ready
to
share
about
the
internal
latency
of
different
at
different
points
within
the
the
out
path
in
loose
or
so
I
I
haven't
talked
to
him
this
week
he's
out
on
vacation,
but
next
week
we
may
have
a
really
interesting
presentation
from
him.
So
I
guess
I
will
hopefully
see
everyone
next
week.
I
have
a
good
day,
guys.