►
From YouTube: Ceph Crimson/SeaStore 2021-12-08
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
Let's
get
started,
let's
see
the
last
week
for
me
has
been
mostly
reviews
and
I
posted
a
version
that
of
that
pr
that
should
fix
the
logical
pin
race,
johnny
how's
it
going.
B
A
B
Oh,
I
just
fixed
the
heartbeat
blank
ipl
issue,
so
the
reason
is
that
in
totality
test,
the
set
dot
configure
file
now
to
set
the
cluster
ip
address
and
the
public
ip
address
just
set
the
monitor
holster
address
and
in
this
case
the
the
chromosome
osd
at
the
beginning,
the
crimson
sd
set
the
heartbeat
round
and
backhand
address
against
zero
the
blank
ip
and
when
sent
sent
the
information
to
the
monitor
it
didn't
check
the
the
copied
ip.
B
C
C
E
Hey
I
just
tried
to
install
with
the
rook
with
the
cluster,
but
unfortunately
it's
like
a
downstream
way
installed.
So
I
just
sync
up
with
radic
and
got
the
input,
I'm
proceeding
with
that,
most
probably
by
next
week.
It
will
be
like
with
the
crimson
build
which
will
be
up
and
then
I'll
start.
My
test
awesome,
cool.
F
Last
week,
I
first
did
some
performance
analysis
for
the
implementation
of
the
sprite
lfs
strategy,
just
based
on
url
in
the
chat
window.
And
after
that
I
did
some
profiling
for
crimson
and
cisdor,
and
the
results
is
here.
F
Also,
I
pissed
it
in
the
chat
window.
I
think
I
I
made
four
observations.
F
The
first
is
that
during
the
profiling,
it
seems
that
a
significant,
a
significant
significant
amount
of
cpu
time
was
occupied
by
by
lba
research
is
caused
by
a
logical
address
and
location
click
collision.
So
I
I
implement
some
optima
optimization
for
it
and
submitted
the
crest
banner
pr.
The
second
observation
is
that,
after
I
made
the
first
optimization,
I
can
see
that.
F
The
lba
research
time
is
still
still
occupying
significant
cpu
cpu
resources,
I
think,
and
they
they
are
almost.
C
F
Caused
by
trying
to
load
o
map
extents
or
o
node
extents,
so
it
seems
that
every
every
o,
node
or
o
map
extends
load
will
have
to
go
through
full
scale.
Lbh
research.
F
I
think
this
this
will
this.
Will
these
searches,
I
think,
will
happen
even
if
the
the
target
logical
address
the
logical
extent
is
already
in
cash,
so
I
think
maybe
we
can.
Maybe
we
can
let
the
parent
knows
parent
logic.
Nodes
article
knows
to
hold
pointers
to
their
children
if
they,
if
those
children
are
already
in
cash,
so
we
can
find
the
load
load,
the
logical
extents,
following
those
pointers
instead
of
going
through
the
lba
tree.
I
don't
know
if
this
is
visible.
A
It's
because
of
the
way
we
do
invalidation
when
we're
doing
when
we're
doing
mutations,
we
keep
like
projected
versions
of
the
extents
attached
to
the
transaction
and
then
add
them
into
the
cache
at
the
end
yeah.
So
it's
it's
more
complicated
than
it
seems,
but
it's
not
impossible.
It's
a
thing
we
may
look
into
in
the
future.
I
think
a
simpler
solution
would
be
to
cash
out
notes.
F
A
In
the
immediate
term,
though,
I
think
the
strategy
should
be
to
take
this
opportunity
to
optimize
the
lba
and
oh
no
treat
lookups.
We
need
to
optimize
them
anyway,
yeah,
like
yeah
yeah.
If
you
do
want
to
start
looking
into
ways
of
doing
the
logical
of
adding
that
kind
of
logical
address.
Caching,
just
keep
in
mind
the
cache
transaction
invalidation,
that's
the
hard
part,
so
any
strategy
there
needs
to
interact
correctly
with
that
and
not
require
and
be
maintainable
and
not
complicated.
F
Oh
yes,
well.
The
third
observation
is
that
almost
30
percent
of
the
cpu
time
is
occupied
by
omap
related
operations,
and
I
think
those
operations
are
caused
by
writing.
Pg
infrared
pigeon
law,
so
yeah,
but
but
this
this
this
doesn't
seem
to
be
our
focus
now
so.
A
Yeah
to
get
some
context,
this
is
a
problem
in
blue
store
too
in
both
blue
store,
so
it
we.
We
need
to
keep
a
record
of
recent
operations
for
reasons
I'm
not
going
to
get
into
right
now,
but
it's
part
of
how
p-rank
works.
They
have
to
be
committed
atomically
with
the
actual
mutation
to
make
recovery
work
correctly.
A
The
way
we
currently
do,
that
is,
we
store
each
log
entry
as
an
omap
entry
on
a
special
pg
log
object
for
each
pg,
but
as
royahan
is
observing.
This
means
that
we
have
to
do
omap
operations
or
every
io,
whether
they
involve
the
omap
or
not.
It's
convenient,
but
not
enormously
efficient,
even
in
blue
store.
It
causes
quite
a
bit
of
rocks
db
overhead,
but
they've
had
to
do
quite
a
bit
of
optimization
there
to
make
it
behave
better.
We
didn't
actually
always
do
it.
A
This
way
before
I
integrated
leveldb
to
use
for
rgw,
we
used
to
just
write
the
log
entries
directly
to
the
binary
payload
of
a
sequence
of
four
megabyte
objects,
and
then
we
just
delete
the
objects
behind
us.
As
we
trim
the
log,
we
could
go
back
to
a
strategy
like
that
or
we
could
use
an
object
as
a
ring
buffer.
A
F
Okay:
okay,
the
final
observation
is
that
it
seems
that
gcs
gc
speed
is
causing
performance
degradation.
The
observation
is
like
this:
before
the
available
space
ratio
hard
limit
is
reached,
I
can
get
I
I
got
nearly
3
000
iops
and
after
that
threshold
is
reached.
I
can
only
get
about
half
of
the
about
1500
iops
and
in
the
in
the
flame
graph.
F
We
can
see
that
about
about
30
percent
of
the
cpu
time
is
occupied
by
various
poles
and
mostly
ai
oppo.
So
I
think
this
is
this.
Is
this
should
be
caused
by
client
tiles
waiting
for
gc
to
reclaim
disk
space?
So
I
think,
maybe
increase
gc
speed
may
give
a
better
performance.
A
Yes,
and
that
will,
in
general,
be
true
by
design,
c-star
or
c-store
will
always
be
bounded
in
speed
by
the
garbage
collector.
What
you're,
observing
with
the
3000
diops,
is
a
regime
where
we're
not
doing
all
of
the
work
associated
with
the
client.
I
o
we're
kind
of
building
it
up.
Then
we've
actually
hit
the
hard
limit
and
we
have
to
be
honest.
We
have
to
do
work
at
the
same
rate
that
work
comes
in
so
generally
speaking,
we
in
order
to
behave
better
under
saturated
load.
A
F
Okay:
okay,
that's
all
my
work
this
week
on.
D
D
How
conflict
is
happening
so
so
it's
used
some
of
the
observations
that
the
cleaning
transactions
have
sound
conflict
with,
imitate
and
read
actions.
A
Well,
I
owe
you
reviews
on
the
merges.
I
will
try
to
get
to
those
this
this
this
week
I
looked
over
them
briefly
looked
reasonable.
I
just
need
to
do
the
review
for
real
sorry
about
that.
I've
gotten
behind.
A
A
Do
we
have
anything
else
to
talk
about
anyone
else?
Have
any
any
topics
to
bring
up?
Did
I
miss
anyone.