►
From YouTube: Ceph Crimson/SeaStore 2021-05-05
Description
A
So,
let's
start
and
last
week,
I've
I've
been
reviewing
pr
and
another
one
from
redtech
and
also
discussed
the
first
one
with
with
you
and
redec
respectively,
and
I
also
send
a
mail
to
the
team
for
further
discussion
on
the
ordering
in
a
futurist
store.
And
let
me
commit.
B
I
provide
a
sister
or
proof
counter
a
pr
and
a
damper
proof
counter
pr
and
I'm
currently
I'm
reviewing
sam's
pr.
That's
all.
C
A
D
Since
last
week,
mostly,
I
was
working
on
in
classical
osd
around
the
around
the
secret
handler.
However,
for
crimson
I
made
I
made
an
actually
just
working
on
small,
optimization
related
to
replication.
D
D
Similar
thing,
similar
algorithm
is,
is
being
used
in
classical
osd
in
our
in
crimson.
The
arrangement
could
be
in
some
cases.
Okay,
mostly
we
we
we
wait
on
on
a
local
store
which
could
increase
latency.
D
E
Hi
everybody
first,
there
are
two
pr's.
I
remind
you
that
if
anybody
has
time
to
read
and
review
two
pr's
that
actually
change
classical
osd
scrub
on
the
way
to
have
a
matching
crimson
implementation,
that's
first,
I'm
now
working
on
testing
what
I
wrote
for
a
scrub
back
in
part,
the
part
that
checks
that
actually
compares
objects,
compares
snaps,
etc,
and
I'm
testing
what
I
wrote
as
part
of
classic
and
but
the
code,
the
password
snap
parts
which
does
not
exist.
E
E
E
I
I
I
think
it's
better
to
have
the
full.
I
ran
small
groups
of
the
which
filtered
with
either
thrashing
or
a
scrub.
This
is
usually
what
I'm
using,
but
I
didn't.
F
F
A
G
Sorry
I
was
working
on
the
design
of
the
interface
of
a
blog
device
mapper,
which
is
supposed
to
be
to
serve
as
a
proxy
layer
between
the
systolic
transaction
manager
and
segment
and
segments
or
random
blog
managers.
Here,
here's
the
link
of
the
documentation.
C
G
Okay,
I.
G
C
F
That's
it
as
far
as
the
c-store
thing
you
asked
about
kifu,
the
assumption
is
that
when
do
transaction
returns,
the
operation
is
already
sequenced.
A
C
A
Yes,
by
two
two
futures
I
mean
one
is
the
the
interface
which
we
are
using
for
sending
a
request
down
to
when
serving
a
client
request.
We
changed
a
bunch
of
continuations
right
sure,
one
of
them
to
be
physic
when,
when
performing
a
mutation
to
to
the
cluster,
to
an
object
to
specific,
we
need
to
wait
for.
A
F
F
F
C
C
A
Johan,
do
you
have
any
comments
regarding
to
this
design?
I
think
you
added
two
two
more
places
in
in
the
pg
pipeline
to
facilitate
the
the
parallelism
when
processing
their
requests.
G
I
think
no,
no,
no!
I
I
don't
have
any
more
comments
on
it.
A
Because
if
you
look
into
the
pr
I
was
referencing
the
in
the
in
the
mail
39772,
where
johan
introduced
to
those
two
things,
one
is
to
introduce
an
another
two
stages
in
the
pipeline
pj
pipeline.
Another
thing
is
to
to
pass
down
a
copac
down
to
the
object
store
to
get
notified
when
the
object
stores
accept
the
request.
F
F
A
F
G
Right
so
sorry,
I
I
don't
quite
follow.
How
do
we
know
when
the
ordering
of
the
alps
as.
C
A
Because
we
could
fail
when
the
senator
transaction
down
to
the
object
stall
exclusively
raised
by
another
one.
So
we
need
to
wait
until
the
two
transaction
returns.
C
F
Wait,
that's
that's
not
true.
Hang
on
racing
will
not
cause
a
transaction
to
fail
c
store
internally
will
redry
it.
A
C
A
F
A
F
F
F
C
F
F
It's
it's
precisely
no
different
from
calling
into
q
transaction
in
classic
osd.
There
isn't
a
callback
that
indicates
when
the
when
the
operation
is
ordered.
When
q
transaction
completes
that's
when
the
operation
is
ordered,
it
will
be
some
time
later
before
the
callback
resolves,
but
that's
immaterial
to
the
ordering.