►
From YouTube: Ceph Crimson/SeaStore 2021-05-12
Description
A
So,
let's
start
last
week,
being
I've
been
doing
code
reviews
and
investigated
the
difference
and
the
percent
cons
of
the
resistor,
metrics
and
and
our
own
performance
counters.
Probably
we
could
discuss
in
more
details
of
the
meeting.
B
B
It
is
in
the
master
branch,
I'm
not
sure
what
the
segment
thought
caused
by
the
later
pr-
or
it
is
maybe
already
has
the
signature
fault,
but
when
the
patch
merged
in
I,
it
passed
my
test
and
I
think
it
already
posted
when
the
patch
merged
in
is
already.
I
think
the
system
is
already
tested,
but
apparently
I
found
there
is
there's
a
segment
default,
so
no
debug
on
it.
B
This
must
branch.
There
is
a
segment
default,
not.
A
B
Okay,
but
currently
branch
master
branch,
I'm
not
sure,
maybe
my
something
wrong
with
my
environment,
but
the
system
will
test
all
the
unit
tests
right.
I
want
the
pr
module.
C
C
B
Okay,
so
you
remember
it's:
oh
okay!
Well,.
B
Crab
just
a
currently
master
branch
right,
yeah
well,.
C
B
A
C
C
B
A
C
All
right,
so
a
pull
request
merged
that
makes
v
start
able
to
actually
start
node's
usc
store.
It
mostly
crashes,
though
so
that's
progress.
I've
got
a
pull
request
up
that
I
hopefully
will
merge
in
a
few
minutes
once
the
test
pass.
That
adds
both
blue
stor
and
c
store
to
crimson
store
nbd
the
network
block
device
adapter
for
just
doing
basic
testing.
The
main
use
here
is
that
it's
less
annoying
to
crash
c-store
using
crimson
store
nvd
than
by
starting
up
an
osd.
C
So
that's
how
I
plan
to
do
the
next
phase
of
debugging,
so
the
bug
that
we're
running
into
right
now
with
c-store
is
that
the
o-node
manager
doesn't
handle
conflicts
correctly,
because
any
of
the
extents
under
it
might
get
might
become
invalid
at
any
time.
Realistically,
this
is
sort
of
really
inconvenient
actually
for
consumers
with
transaction
manager
interface
and
it's
a
consequence
of
the
way
I'm
doing
conflict
detection.
C
C
This
is
correct
as
far
as
it
goes,
but
it
means
that
during
execution
of
a
transaction
any
of
the
reader
write
state
might
be
operating
on
invalid,
extents
that
have
been
well
replaced,
which
means
that
the
read
snapshot
you
get
isn't
strictly
speaking,
consistent,
it's
sort
of
harmless
because
the
transaction
won't
commit
so
anything
stupid.
It
does,
in
the
meantime,
won't
be
able
to
affect
anything
else,
but
it
does
make
the
logic
that
implements
that
code
hard
to
get
right.
C
Then
all
of
the
code
in
the
store
will
be
converted
to
use
interruptable
future
to
check
the
invalidation
state
of
the
trend
of
the
transaction.
That
should
basically
eliminate
this
entire
category
of
bug
and
basically
make
all
of
the
consumers
of
the
transaction
manager
interface
able
to
ignore
it.
C
C
Okay,
I
think
it'll
simplify
things
too.
A
A
C
Now
doing
it
we're
not
really
doing
it
in
transaction
manager,
by
converting
all
of
the
users
to
use
by
converting
all
of
the
users
to
use
interruptable
future
it'll
essentially
be
doing
what
you're
describing
every
time.
C
A
C
A
C
A
C
C
Well,
I
mean
I'm
just
I'm
doing
I'm
using
them
the
same
way.
The
osd
does
just
with
different
errors
and
a
different,
well
check
function,
but
that's
definitely
plugable
from
what
I
could
see.
C
C
Like
every
everywhere
that
fl
tree
pauses
and
comes
back
is
an
I
o
function,
it's
invoking
on
transaction
manager,
that's
literally
all
right,
so
every
in
every
one
of
those
cases
by
replacing
the
aerator
type
with
an
interruptible
future
type.
When
it
comes
back,
it
will
transparently
check
the
state
of
the
transaction
and
it'll
propagate
an
e
again
error
from
that
point.
D
A
C
C
C
C
Yeah,
hopefully,
that
should
be
mostly
it,
though,
because
the
the
entire
the
entire
architecture
is
that
when
we
get
an
e
again,
we
zip
all
the
way
back
out
to
the
function
that
called
into
c
store
pretty
much,
and
we
dump
all
that
state
and
call
its
destructors
legally
blast
it
and
start
over
from
scratch.
So
hopefully
it
should
be
just
a
matter
of
making
sure
that
you're
not
holding
any
locks
or
resources
or
anything
like
that,
and
that.
D
D
C
There
will
be
some
other
advantages.
The
read
set
right
now
is
like
really
naive.
It
uses
like
a
literal
stl
map,
which
is
exactly
as
inefficient
as
it
sounds,
because
it's
allocating
the
background
so
converting
it
to
this
will
mean
we're
using
intrusive
list
members
that
are
pre-allocated
as
part
of
the
transactions,
so
we'll
avoid
that
level
of
allocations,
which
should
make
it
faster.
D
D
C
There's
a
pull
request
for
the
random
block
manager
as
well.
If
you're
interested.
C
D
A
C
A
Before
concluding
the
meeting,
I
I
wanted
to
to
bring
bring
up
the
discussion
regarding
the
the
system
clinical
metrics
versus
prof
counter.
I
I
I
read.
I
brought
this
up
in
last
stand
up
last
night,
but
I
really
want
to
have
your
opinion
on
on
this
comment,
because
you
are
you're
the
one
working
on
perfect
counter
and
with
under
the
pr
which
brings
brings
the
perfect
country
to
into
sister
sister.
A
The
reason
why
I
think
sister
magic
is
superior
from
the
perfect
from
the
from
the
future
perspective
is
that
a
sister
on
matrix
has
had
built
into
particular
charts.
Each
matrix
has
a
label
named
nate?
Has
a
label
named
shot
which
value
is
the
short
number?
That's
the
building,
support
of
the
matrix.
In
addition
to
that,
we
are
allowed
to
attach
more
labels
to
to
each
matrix,
for
example,
the
the
pg
numbers
and
the.
A
If,
if
that
that,
if
we
are
looking
at
some,
some
slow
request,
metrics
and
and
we
can
also
apply
labels
of
them,
for
example,
the
denotes
the
device
id
or
the
device,
the
type
of
device
to
to
the
I,
the
I
o
number
of
device
storage
device
or
the
delays
total
number
of
the
delay
on
such
kind
of
device.
So
I
think
that
will
be.
A
C
A
Not
exactly
actually
each
matrix
is
is
represented
by
a
lambda
which
returns,
which
could
return
a
reference
of
number
or
it
could
be
calculated.
The
number
could
be
calculated
on
the
fly
and
each
lambda
is
attached
by
a
set
of
labels,
and
also
the
name
and
the
group
name
of
this
metric.
A
So
at
runtime
sita
offers
the
method
allowing
us
to
to
dump
to
carry
the
num
the
metric
by
it's
the
good
name,
and
it's
it's
a
name,
but
it
does
not
allow
us
to
to
query
by
labels.
We
need
to
have
this,
have
this
feature
in
in
an
offline
tool
like
premises
or
our
building
manager,
module.
C
C
I
don't
really
care
about
the
querying
part
like
if
we
just
dump
all
the
numbers.
That's
all
I
care
about.
Perf
counters
actually
creates
a
struct
in
memory
in
a
per
shared
basis,
for
what
we
have
now,
where
we
can
just
increment
a
counter
like
if
metrics
don't
provide
that,
then
I
don't
think
that's
really
relevant
to
this
conversation
right
now,.
A
C
C
A
C
That
that's
not
really
the
point.
The
point
is
that
we
want
a
common
way
of
doing
this
so
that
all
of
the
code
that
increments
a
particular
counter
looks
the
same.
That
way
if
someone's
like.
Oh,
I
need
a
counter
to
count
the
number
of
reads:
they
don't
have
to
go
and
implement
a
new
thing.
They
just
add
another
proof
counter
for
reads,
and
it's
just
there
right,
there's,
no
there's
no
extra
step,
like
proof
counters.
B
C
C
A
C
A
If
you,
if
you
can
just
grab
for
the,
for
example,
at
a
counter
which
is
a
api
expert
by
crimson,
oh
sorry,
the
system
matrix
and
you
will
find
how
the
metric
is-
is
associated
with
a
tangible
variable
right
in
systole
or
in
crimson.
B
So
I
think
proof
culture
has
something
similar,
improv
contour
has
name
so
the
name
with
shard
id,
and
so
each
charter
can
have
the
different
proof
counter
instances.
B
It's
just
one
one
collection
and
you're
ready
to
put
counter
into
the
collection,
so
each
proof
counter
on
different
chart
has
different
name,
the
name
with
the
shadow
id,
and
then
we
can
identify
the
counter.
That's
not
the!
I
don't
think
the
label
is
the
necessary.
It's
the
important
reason
I
care
about
the
performance.
C
Metrics,
probably,
probably,
output,
sorry,
probably
outputs
those
labels
in
a
way
that
prometheus
is
able
to
consume
and
in
prometheus
it
actually
does
matter.
Prometheus
will
be
able
to
tease
apart
those
things
into
tuples
of
related.
That's
what
you
can
then
do
queries
on.
It's
a
valuable.
It's
a
valuable
feature.
It's
not
that
I'm
arguing
so
much.
C
C
A
C
I
know
I
want
it
to
be.
I
want
the
number
itself
to
state
for
it
to
be
stored
in
that
struct,
though
I
want
to
be
initialized
there
and
which
we
can
do.
We
can
just
create
a
a
wrapper
around
c-star
metrics
yeah
that
exposes
things
to
c-star
metrics
like
the
same
way.
Perf-Counters
does
basically
but
keeps
the
numbers
inside
the
struct,
which
is
fine.
C
So
I'm
I'm
fine
with
that,
but
you
know
I
don't.
C
C
C
I
would
like
a
perf
counters
like
interface,
for
interacting
with
it
and
defining
them,
something
where
you
you,
there's
like
a
metrics
collection
defined
on
the
comp
thing
that
you
just
accessed
kind
of,
like
the
proof
counters
one.
You
add
counters
to
it
with
defined
types
again
like
proof,
counters
and
names,
and
then
behind
the
scenes.
The
c
star,
metrics
adapter,
will
add
out
the
other
labels
that
are
c-star
specific,
like
label
and
like
a
jardin
node
id
before
exposing
them
to
the
greater
c-stars
metric
subsystem.
A
C
A
A
A
system
metric
because
using
using
each
collect
using
a
collection
for
each
chart,
can
also
can
only
enable
us
to
use
a
single
label
for
each
metric.
But
when
it
comes
to
the
system
metric,
we
are
able
to
attach
multiple
labels
in
addition
to
the
short
label
to
a
metric,
which
would
be
very
valuable
for
us.
C
C
C
A
C
C
A
C
Well,
I
mean
if
we
we
do
need
perv
counters
and
as
we
so
I
actually
think
this
is
important
like
we.
We
need
counters
in
general
because
we're
about,
as
we
start
getting
technology
tests
to
pass
more
often
almost
immediately.
The
next
focus
will
be
improving
performance
and
good.
Metrics
are
like
a
really
important
component
of
doing
that.
So
I
do
think
this
is
important,
so
I'm
I
I
think
what
we
should
do
is
go
ahead
and
merge.
Sun
maze,
change
and
then
also
start
working
on
c
star
metrics.