►
From YouTube: Ceph Crimson 2021-02-23
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).
B
B
C
Yeah
on
my
implementation
or
in
my
built
environment,
the
release
build,
does
work
and
it's
about
10
times
faster,
give
or
take.
C
Yeah,
what
you're
seeing
is
a
timing,
related
crash
or
a
difference
in
how
the
reactor
is
doing
scheduling
you
may
be
able
to
find
it
by
inspection
if
you
start
reading
code,
if
you
don't,
though,
I'm
I'm
not
hyper
interested
in
this
just
now,
because
I'm
still
making
changes
to
those
bits
of
code
and
I'm
about
to
want
to
get
a
little
bit
further
in
integrating
the
o
node
map
and
collection
interfaces
into
c
store.
C
I'm
gonna,
add
c
store
itself
to
that
tool,
at
which
point
I'm
gonna
have
to
do
yet
another
round
of
debugging,
so
it
this
may
just
be
a
thing
to
do
later.
Basically,
but
if
you
want
to
debug
it
you're
welcome
to,
I
just
don't
have
enough
information
at
this
time
to
do
so.
You
might
be.
B
C
C
B
Sure
so
I
will
add
some
messenger
under
log
some
error:
messenger.
Okay
to.
C
When
I
try
to
debug
this
myself,
what
I'm
going
to
do
is
I'm
going
to
start
by
trying
to
change
details
of
how
the
block
implementation
works
until
I
get
lucky
and
I'm
able
to
reproduce
it
myself.
I
think
that's
what
I
have
to
do.
What
kind
of
hardware
are
you
running
on
by
the
way.
B
B
C
C
Well,
no
that'll
get
rid
of
the
bug
which
isn't
we
want
to
fix
the
buck.
The
goal
isn't
to
avoid
the
bug.
The
goal
is
to
forget,
I'm
trying
to
work
out
what
what
I
need
to
do
to
emulate
your
environment
but
the
trump,
but
if,
if
you're,
basically,
if
you're
running
on
faster
hardware
than
I
have,
then
I
don't
have
any.
I
can't
do
anything
with
that,
because
I
don't
have
anything
faster
than
the
part
where
I
have,
although
I
could
check
the
cpu
lab.
C
Actually,
I
think
there
are
some
with
faster
pcie
drives
anyway.
That's
what
I'll
look
into
when
I
get
around
to
it.
I
would
move
on
to
something
else
for
the
time
being,
though,
if
you
don't
want
to
spend
time
debugging
up.
C
A
D
Last
week
I
worked,
I
worked
with
food
and
with
with
an
optimization
for
the
client
request,
sequencer,
and
I
also
reviewed
some
some
of
his
pr's
and
right
now,
I'm
working
on
optimizing,
the
parallelism
of
the
crimson
osd,
specifically
the
parallelism
of
its
cloud
request
pipeline.
I
have
one.
I
have
one
question.
I
think
the
correctness
of
this
parallelism
optimization
is.
I
rely
on
one
point
that
the
quest
for
the
client
request
are.
D
The
client
requests
are
persisted
to
the
underlying
disk
in
the
exact
order
of
their
of
their
arrival
at
the
osd.
So
I
think
the
classic
osd
accomplished
this
by
first
making
sure
that
there's
only
one
one
cloud
request
for
each
pg
at
any
at
any
time
point
and
the
blue
store
would
make
sure
that
that
the
client
requests
are
persisted
to
the
underlying
disk.
In
the
exact
order
base
they're
submitted
to
the
blue
store.
D
Okay,
but
after
reading
the
code
of
alien
store,
I
think
if
we,
I
think,
I
think
it
seems
it
looks
to
me
that
the
alien
store
doesn't
provide
the
same
guarantee
that
it
would
persist
in
the
client
requests.
D
Because,
oh
when
we
submit
a
client
request
to
the
alien
store,
the
alien
store
cash
it
in
in
a
buffer
and
there's
a
threat
pool
right
in
there.
There's
a
there's
there
are
that
threat
pool.
Will
us
submit
the
the
client
request
to
blue
store,
but
the
order
the
threat
pool,
submits.
D
To
the
usd
unquote,
I
I
mean
the
order
of
the
pg
log
entries
correct.
C
So
the
point
at
which
we
decide
what
order
of
the
pt
log
entries
is
that's
the
order
they
have
to
be
persistent
in
the
object
store.
That's
that's
right.
Let's
go
look
at
alien
store,
real
quick,
all
alien
store
really
has
to
do
is
ensure
that
the
order
of
submission
matches
the
order
of
submission
to
bluestora.
D
I'm
correct
about
this,
but
I
think
it
he
just
you
just
pull
all
the
requests
out
of
the
buffer
and
submit
to
the
store.
C
B
C
Okay,
you're
right:
this
is
wrong.
This
won't
work.
D
Okay-
I
I
want
I
want
to.
I
want
to
make
sure
that
c-store
would
guarantee
that
okay,
okay,
so
I
just
have
to
do
some
work
within
the
plane
within
the
alien
store
right.
C
You
may
assume
that
operation.
This
is
an
this-
is
an
interface
property
of
the
futurized
store
interface.
Anyone
any
any
implementation
that
fails
to
uphold
it
is
buggy,
so
the
bug
is
to
be
addressed
in
the
implementation.
Not
in
your
code.
Does
that
make
sense.
Okay,
yeah,
it
doesn't
make
sense
to
me.
The
specific
guarantee
is
that
any
two
transactions
submitted
on
the
same
collection
will
be
completed
in
that
order.
C
Okay,
all
bets
are
off
if
they're,
on
different
collections,
of
course,
but
that's
different.
C
So
in
the
meantime
donate
I
don't
think
we've
got
to
answer
this
is:
are
there
ever
two
threads
here?
Where
does
the
thread
pool
always
just
one.
A
A
Yes,
that
defeats
the
the
purpose
of
increasing
the
number.
No,
it
doesn't
why.
B
D
Oh
yeah,
it
is,
I
think,
that
that
new
text
is
guaranteeing
the
order.
The
client
requests
are
submitted
to
the
alien
store,
not
any
store
to
blue
store
right.
C
C
C
D
I
am
trying
to
to
to
do
that.
I
just
don't
know
if
it
is
correct
to
implement
those
those
corrections
within
the
scale
of
install.
I
think.
C
So
yeah,
so
one
really
simple
way
to
do.
This
would
be
to
hash
the
collection
onto
the
set
of
threads
so
that
any
two
transactions
in
the
same
collection
end
up
on
the
same
thread
that
should
guarantee
ordering
you
may
have
to
look
at
the
thread:
pool
implementation
with
an
within
c
star
to
make
sure.
But
that's
how
I
would
do
it.
C
A
C
C
Believe,
but
I
think
the
thing
you
should
look
for
most
is
that
c
star
should
have
its
own
way
of
doing
this.
It
should
have
its
own
utility,
for
this
would
be
the
simplest
way
to
do
it.
A
C
Very,
very,
very,
very
common
in
distributed
pro
programming,
though
I
I
bet
c-star
already
has
a
library
for
this
the
same
way,
it
already
has
a
library
for
a
thread
pool
in
the
first
place.
B
B
C
Isn't
there
is
an
ordering
that
is
not
total.
If
there
were
total
ordering,
then
having
multiple
threads
be
pointless,
you
could
only
ever
utilize
one,
but
if
you
have
a
a
sub
ordering
some
kind
of
lattice
sub
ordering
within
that
set-
and
you
can
say
and
partition
all
of
the
incoming
things
among
a
set
of
tokens
and
say
any
any
two
things
that
map
to
the
same
token,
they
they
have
an
ordering
restriction.
C
D
A
We
could
we
need
to
have
a
dispatcher
which
could
dispatch
the
the
request
with
different
tokens
and
the
dispatchers
to
the
right
right.
C
A
C
C
Two
threads
do
happen
to
grab
this
the
same
collection.
At
the
same
time,
only
one
of
them
will
pull
the
next
stop
off
so
that
that
would
be
a
crude
but
simple
way
of
ensuring
ordering
and
yeah
I
mean
I
I
wouldn't
overthink
it
I
I.
I
think
this
probably
won't
turn
out
to
be
a
bottleneck,
but
if
it
is
well
we'll
put
some
more
effort
into
it
after
we
have
actual
benchmark
numbers
better
to
be.
B
B
C
D
C
Okay,
where
each
op
sequencer
our
collection,
these
days
has
a
queue
in
it
and
you
don't
so
when
you
cue
things
for
the
thread
pool
you,
don't
cue
the
thing
you're
queuing
you,
you
first
put
it
into
the
queue
for
the
sequencer,
and
then
you
keep
the
sequencer.
C
C
New
text
in
the
sequencer
they'll
get
the
next
operation
which
is
well
defined,
submit
it
release
the
lock
and
then
move
on
with
their
lives.
In
this
way,
we
guarantee
that
as
long
as
we
enqueue
and
dequeue
the
sequence
or
the
same
number
of
times,
we'll
always
go
through
the
full
queue
we'll
do
it.
A
C
C
The
thread
pool
calls
calls
blue
store,
submit
transaction
in
the
same
order
in
which
things
were
cute
for
the
red
pool
and
submit
transaction
maintains
ordering
itself,
because
blue
store
is
correctly
coded,
then
we're
fine.
C
All
we're
talking
about
here
is
basic
ways
of
doing
maintaining
ordering
among
of
items
queued
for
work.
You
it's
a
pretty
basic
problem
and
you're
correct.
If
all
of
the
things
were
cute
on
the
same
pg,
there
is
no
way
for
us
to
make
use
of
two
cores.
C
D
C
C
This
isn't
a
picture
like
I
said
it
has
no
clue
that
this
isn't
about
c
star.
This
is
about
c
store,
actually
just
ignore
everything
I
just
I
I
just
said
in
normal
course
of
events.
If
you
have
to
process
ten
things
in
order,
there
is
no
way
to
do
that
on
two
course.
They
must
be
done
on
a
single
core
in
order
you
can
bounce
them
between
cores,
but
that's
not
really
utilization
right.
So
the
way
we
get
parallelism
here
isn't
by
processing
the
same
pg
across
multiple
cores.
It's
by
having
100.
C
A
C
The
other
half
is
is
also
really
what
I'm
trying
to
tell
you
it's
it's
fundamentally
impossible.
It's
a
logical
impossibility
to
do
otherwise,
as
long
as
we
require
operations
to
be
ordered
between
where
the
pg
sets
the
pg
log
entries
and
where
they're
committed
to
disk,
we
are.
C
C
Achieve
more
power,
more
parallelism
than
the
ratio
of
the
longest
sequential
portion
of
a
computation
execution
to
the
overall
computation
required.
So
if
half
of
the
total
computation
required
is
fundamentally
sequential,
then
the
best
speed
up
you
can
get
is
a
factor
of
two.
In
our
case,
a
hundred
percent
of
it
is
sequential
so
on
a
single
pg.
The
best
you
can
get
is
a
speed
up
of
one.
You
can't
use
two
cores.