►
From YouTube: Ceph Crimson / SeaStor OSD 2020-09-02
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
Assume
we
have
a
fulcrum
here.
The
last
week
I
was
still
working
on
the
tesla
based
strategy
test
side
and
I
have
a
a
new
failure.
A
A
A
So
that's
it.
I
can
make.
B
Yeah
so
so
excitement
trim
has
already
updated
the
force
for
some
days,
and
so
please
reveal
it.
It's
no
problem,
please
approve
and
move
in
and
I'm
debugging
on
the
old
map
on
my
tree
code
currently.
C
A
Just
out
of
curiosity,
what
what
tool
do
you
do?
Are
you
using
for
for
illustrating
the
diagram
using
data
or
something.
A
Thank
you,
sam.
D
I
think
I
have
basic
space
accounting
working.
I
have
to
do
some
debug
related
to
that,
so
I'm
on
to
doing
segment
scanning
and
cleaning.
That
should
be
it.
E
Last
week
I
was
still
improving
the
interrupt
a
little
later
future.
It's
the
coding
is
almost
done
now,
but
yesterday
I
had
small
discussion
with
radic
and
it
seems
we
have
an
issue
about
running
erratic
future
and
system
future
simultaneously,
and
I
think
maybe
we
can
discuss
it
later
in
this
meeting
and
that's
all
for
me.
A
Okay,
we
can
do
that
issue.
B
A
Fantastic.
Thank
you.
By
the
way
I
I've
been
sporting,
some
from
test
failures
recently
in
unity
to
assist
messenger
system,
messenger.
Okay,
did
you
get
a
chance
to
see
to
look
into
it
yeah?
I
do
have
a
link
sure
I
will
send
a
link
offline
to
you,
okay,
and
also,
as
you
ping
you
over
the
github.
There
are
two
occurrences,
so
I
think
it's
probably
the
regression
after
you
fix
the
the
unit
test.
A
Oh,
I
will
take
a
look.
Thank
you.
I
will.
I
will
pick
you
with
with
with
backtrace
and
error
message
in
a
in
the
email.
C
Sure,
yesterday,
yesterday's
evening,
I
posted
a
guest
exemplifying
the
problem
I
am
seeing
with
the
current
implementation.
C
I
think
that
it,
the
okay
a
little
bit
more
background.
The
error
rate,
the
interruptible
error
test
code,
makes
an
assumption
about.
C
C
This,
where
we
know
when
we
as
fast
understood
where
we
offer
no
synchronization
at
all
and
when
the
our
code,
when
the
when
the
elevated
futures
are
combined
with
sister
vanilla
futures,
it
cultivates
to
trashing
the
interrupt
condition
start
as
a
as
a
thread.
Local
actually
stood
as
a
static
single
member
of
england.
C
Memory.
That's
that's
my
that's
my
that's
the
issue
with
the
implementation.
However,
I
am
afraid
that
there
is
a
much
more
fundamental
issue
with
the
concept
of
actually
after
the
change
set.
Aerator
is
not
error,
pure
a
record
anymore.
I
mean
it
goes.
It
goes,
got
additional
responsibilities.
C
My
feeling
is
that
it
should
be
actually
renamed
aerator
and
interrupter
would
be,
would
be
the
name
pointing
now
the
purpose
after
after
the
change
set,
we
are
mixing
responsibilities.
One
single
okay,
one
component,
pretty
complex
one
got
multiple
responsibilities,
I'm
not
sure
it's
the
way
to
go.
C
No,
no,
no
way
an
original
idea.
No
original
idea
about
mixing
the
different
kinds
of
different
levels
of
adoration
was
that
a
less
aerated
future
can
be
always
assigned
can
be,
can
be
always,
let's
say,
moved
to
more
error-rated
future
vanilla,
vanilla,
uavs,
vanilla,
sister
future
is
a
special
case.
C
D
But
more
more
more
practically,
so
we
do
need
to
be
able
to
mix
interruptable
futures
and
error
in
futures,
because
we
kind
of
expect
nearly
every
process
to
be
aerated.
So
then
they're
very,
very
interesting
things
hang
on
inside.
They
don't
involve.
I
o
in
some
way,
so
all
of
them
need
some
way
of
propagating
exceptional
outcomes
and
at
the
same
time
there
are
very
very
few
processes
and
stuff
where
we
don't
want
a
way
to
interrupt
the
callback
chain.
D
C
D
B
D
C
B
D
That's
where
this
started
right
that
it
was
difficult
to
do,
because
you
necessarily
need
a
way
for
the
for
the
interrupt
for
something
that
is
interruptable
to
call
into
something
that
isn't,
or
vice
versa.
That
is
the
handling
chain
itself
has
to
be
agnostic.
It
can't
care
what
the
intermediate
calls
return,
because
it
needs
to
be
able
to
handle
the
worst
case,
which
is
that
interruption
is
possible.
D
C
D
C
But
before
going
with
that,
let's
maybe
let's
reiterate
the
original
problem
and
that
lead
us
to
touching
generator.
I
saw
that
when
it
comes
to
when
it
comes
to
the
interruption,
we
actually
glue
two
different
errors:
extra
responsibility,
one
is
about
the
graceful
shutdown
sure
it's
stopping
it.
That's
part
of
stopping
pg,
but
the
second
one
is
about
snapshotting
the
pg
epoch.
C
In
turn,
it
hasn't
changed
when
when
this,
when
this.
D
D
C
Okay,
so
I
see
we
expect
even
more
okay.
I
was
thinking
about
the
third
one
which
is
actually
you
know
this
system
talked
some
time
ago,
maybe
two
months
they
changed
the
interface,
the
public
interface
of
future.
It
doesn't
care
about
starvation,
it
doesn't
call
needs
preempt
anymore,
it's
a
responsibility
of
of
user
at
the
moment,
so
I
bet
that
sooner
or
later
we
will
need
to
with
with
at
least
third
use
case
for
for
blowing
responsibility
for
for
glowing
into
a
generator.
C
C
C
Well,
it's
down
about
our
restrictions,
requirements
of
of
the
hooks
sure
we
can
put.
We
could
put
an
std
function
there,
but
you
know
it
won't
be.
It
won't
be
super
super
fast.
A
C
And
and
the
last
change
that
from
sichuan
actually
introduced
if
cons
x,
checker
for
for
the
empty
for
the
empty
interruption,
condition.
A
We
need
to
support
like
multiple,
multiple
predicators
in
in
machinery.
If
you
want
to
have
a
like
plugable
system
for
for
aerator,
which
supports
one
or
more
predicators,
we
need
that.
A
C
Predicators
but
okay,
what
will
this
mean
when
it
comes
to
just
practicality,
pure
practicality?
C
It's?
How
do
we
ensure
okay,
the
current
hook?
The
current
interrupt
condition
hooking
requires
requires
not
mixing
with
sister
future
at
all.
It
would
mean
that
only
aerator
aerator
that
aerator
needs
to
handle
ever
literally
everything.
C
I'm
not
sure
it's
doable
to
be
honest.
Okay,
maybe
we
could
change
the
sis,
the
vanilla
sister
future,
but
it
means
actually
okay,
convincing
abby
and
company
to
to
introduce
some
hooks
to
sister
future,
which
could
be
quite
hard.
I
am
afraid
they
are
really
focused
on
the
on
its
performance.
They
are
they
cut
off.
Even
that
needs
a
preamp
track
on
the
other
and
as
an
alternative
we
could
fork
our
we
could,
for.
We
could
add
more
patches,
yeah.
I
I
I'm
seeing
here
earlier.
Maybe
your
mimic.
C
A
D
C
Okay,
you,
you
are
thinking
about
what
there
is
when
it
comes
to
save.
Then
I
mean
I
mean
speaking
about
the
session
when
your
current
implementation
in
safe,
then
17
is
implemented
in
that
way
that
it's
actually
an
overlay
over
then
wrapped
of
vanilla
future,
and
we
are
passing
some
extra
lambda
there.
This
lambda
is
used
by
szechuan
to
make
the
cup
to
capture
the
interrupt
condition
and
to
restore
it
when
executing
the
high
level.
C
The
high
sure
this
actually
it's
some
kind
of
guard
for
for
tusk
switch
in
in
a
reactor.
C
If
we
could
move
if
we
could
get
some
hook
inside
the
reaction
task
in
the
task
switcher
and
the
guy
who
is
responsible
for
switching
tasks,
we
could
move
the
check
the
we
could
move
the
restoration
of
the
count
interrupted
there.
D
C
D
D
It
would
have
to
be
no
it
would
it
would.
It
would
have
to
look
like.
Are
you
done
yet?
Are
you
done
yet?
Are
you
done
yet
until
you're
done
right?
I
think
that's
what
the
interface
looks
looks
like
and
a
way
of
pulling
for
ready
to
go
for
the
next
thing.
So
it's
a
kind
of
a
combination
of
replacement
problems
in
the
future,
but
I'm.
B
D
D
C
C
C
The
future
component,
and,
to
be
honest,
I
mean
it
seems
as
the
only
way
you
are.
You
are
as
understood
to
your
concept.
You
are
thinking
about
about
introducing
some
extra
hooks
at
the
level
of
task
sister
task,
but
this
is
who
is
responsible
for
creating
a
task
of
attenuation.
When
I
mean
in
the
case,
when
then
is
called
an
unfulfilled
future
is
actually
the
sister
future,
so
you
would
need
to
change
that.
C
D
This
isn't
complicated
there.
There
needs
to
be
what
this
is
true
throughout
the
existing
osd
code.
Basically,
every
time
we
take
a
lock,
we
have
to
check
for
things
still
being
being
valid
in
the
pg.
It's
almost
always
the
osd
epic
in
the
osd.
It
can
be
a
few
things,
but
one
of
them
is
that
with
the
osd
map
we
still
have
it
still
valid
in,
and
I
remember
what
it
doesn't
blooster,
but
there's
something
analogous
it's
just.
There
needs
to
be
a
way.
D
A
D
That
depends
100
on
what
the
intent
of
the
code
is.
For
instance,
if
you
are
currently
processing
a
read
and
you
observe
that
the
osd
effort
changed,
you
have
to
drop
the
read
on
the
floor
immediately.
You
can't
return
a
result.
D
D
I'm
sorry,
but
it's
very,
this
is
a
general
problem.
We
do
a
bunch
of
asynchronous
things
and
sometimes
the
chain
of
asynchronous
things
becomes
no
longer
a
good
idea.
This
is
true
in
a
number
of
different
ways
in
a
number
of
different
places,
but
it
all
boils
down
to
the
same
basic
concept.
Is
it
still
okay
for
me
to
be
doing
what
I'm
doing.
D
D
D
D
D
Have
the
ability
to
say,
as
as
part
of
an
error,
rater
there's
an
interrupt
error
here,
that's
possible
right
and
as
soon
as
you
see
that
you're
no
longer
supposed
to
be
running,
you
simply
return
the
the
interrupt
error
and
to
let
the
caller
deal
with
that,
which
almost
certainly
means
dropping
it
on
the
floor
right
if
a
request
handler
kicks
off
a
chain
of
continuations,
that's
supposed
to
return
to
read
and
it
gets
back
interrupts
instead.
That
means
the
ost
have
changed
big
deal
right.
D
So
that's
that
support
is
already
present
as
part
of
c
star
futurism,
and
you
don't
need
to
need
aerator
for
that.
The
question
is:
do
we
automate
the
thing
where
we
check
the
flag
and
again
I
would
prefer
a
library
solution
to
this.
Embedding
it
into
aerator
is
only
useful
if
it
makes
it
less
annoying
to
use,
but
if
it
turns
out
to
be
very
difficult
or
has
a
large
amount
of
performance
overhead
remember,
we
do
have
the
option
of
just
writing
the
code.
D
Keep
in
mind
that
condition
may
shift
over
the
the
duration
of
an
execution
pathway.
C
Okay,
I'm
buying
some
I'm
buying
here
that
we
need
in
many
places
that
we
need
at
the
taking
machinery.
Sure
I'm
asking
now
about
company
concrete
implemented,
a
writer
got
a
lot
of
extra.
It
got
two
extra
parameters,
template
parameters.
One
is,
of
course,
the
hook.
C
The
the
interrupt
condition
itself.
Second,
one
is
a
is
x,
is
some
kind
of
extra
distinct
set
of
not
errors
interrupts,
and
I
understood
that
this
extra
parameter,
the
distinct
errors,
is
necessary
for
the
sake
of
distinguishing
in
let's
say.
C
C
One
is
for
one
is
the
unthrowable
errors,
the
the
very
fast,
the
very
simple,
the
very
simple
thing?
Second,
when
the
second
one
is
about
state
about
complex
stateful
errors,
I
wonder
whether
it's
whether
we
should
whether
those
actually
interruptions,
those
gizmos
indicate
that
those
interruption
indicators
shouldn't
be
glued
at
this
level.
C
Adding
maybe
adding
some
extra
methods
for
to
indicate
it's,
it's
error,
or
something
like
that
at
the
level
of
error,
t.
C
C
D
I
don't,
I
don't
totally
understand
why
this
works
this
way,
maybe
I'm
confused,
but
why
does
this
need
to
be
integrated
into
the
future
at
all?
D
What
I
see
here
is
you're
returning
a
thing
with
a
ven
method
and
eventually
a
dot
to
future
method.
So
what
does
that
have
to
do
with
future?
You
could
wrap
literal.
I
mean
it
just
needs
to
have
a
ben
method.
It
doesn't
need
actual,
like
the
thing
it
returns
doesn't
have
to
know
that
it's
in
an
interruptible
future
every
one
of
these
dot
venns
could
have
baked
in
the
check.
B
B
E
I
still
don't
quite
follow
you.
I
thought
the
interrupt.
I
thought
he
I
thought
the
interruption
interruption
check
should
be
in
the
continuation
and
yes,.
D
That
would
be
the
library
approach
right,
but
we
didn't
want
to
do
that
because
it
would
be
irritating.
So
the
next
approach
would
be
to
create
a
sort
of
a
super
future
which
simply
wraps
aerator
and
has
a
dot
safe,
then
or
then
method
which
has
nothing
to
do
with
aerators.
That
save
that
method,
whose
only
purpose
in
life
is
to
pass
the
relevant
lambda
through
to
the
wrapped
future,
and
just
you
know,
inject
the
condition
check
ahead
of
it,
which
I
thought
was
what
you
were
doing
here.
But
it
appears
not
to
be.
E
I
thought
I
tried.
I
tried
your
way
in
in
the
past
back
in
july,
and,
first
of
all,
let
me
let
me
confirm
that
you
what
what
you
mean
is
that
oh,
we
wrapped
the
wrap
the
lambda
and
in
in
you
know,
we
wrap
the
lambda
and
in
the
in
the
wrapper
in
the
wrapper,
we
check
the
interruption,
condition
check
the
interrupter
condition.
D
D
E
Yeah
yeah,
I
tried
that
that
will
work,
but
back
in
july
I
tested
and
it
it
turns.
It
seems
that
it
might
involve
much
performance,
overhead
and.
D
E
Okay,
so
we
put
the
performance
at
the
second
place.
E
E
Okay,
so
so
I
think
I
will,
I
will
send
the
performance
test
result
in
the
email
later
and
we
can.
We
can
make
it
we
can
make
a
decision
and
in
the
email
or
right
now
we
make
decision
on
wrapping
up
the
can
wrapping
up
the
the
continue
the
lambda
way,
with
the
samsung
way.
D
B
D
C
E
C
D
Hang
on
no
seriously,
though,
we
want
readers
to
know
that
there's
code
they're
not
seeing
that's
important
but
yeah.
It
would
take
yeah
the
error
that
the
error
function
and
the
other
function
just
like
now
would
pass
it
straight
through
unmodified,
except
for
adding
this
predicate
to
aerator,
specifically.
C
And
that's
the
question:
that's
the
place
where
I
wanted
to
actually
introduce
some
kind
of
hooking
into
aerator.
Just
take
a
look,
the
decorate,
the
decorate
predicate.
He
can
be
actually
parameter
a
template
parameter
to
aerator.
That
was
the
idea
about
cookable
aerator,
and
this
could.
C
C
Okay,
I
started.
I
started
considering
giving
a
small
relaxation
here
the
idea
of
hook
of
introducing
hooks
generator
to
how
to
get
let's
say,
pure
aerator,
interrupt
generator,
whatever
aerator.
D
It
would
take
us
an
argument,
an
incoming,
an
incoming
future,
and
then
it
would
take
a
continuation
chain,
a
specified
set
of
them
and
say
for
each
of
the
continuation
handoffs
in
this
chain.
Please
insert
this
check
before
you
continue.
D
There
are
some
catches
to
this.
There
would
be
nested
futures.
So
let's
say
you
call
into
c-store
and
from
your
perspective,
it's
one
continuation
right,
you
say:
do
I'm
just
go,
do
a
read
and
then
you
get
the
read
back
right:
one
continuation,
but
in
real
life
it's
actually
a
whole
set
of
continuations
c
store.
May
do
several
things
in
the
background
in
the
process
of
serving
that
read
making
multiple
independent
reads,
but
you
don't
ever
see
any
of
those
continuation
calls
as
a
result.
C
D
D
A
D
And
it's
it's
not
it's
both
because
it's
okay
to
do
it
that
way,
and
also
because
it's
simpler
to
do
it
that
way.
Clearly,
it
does
waste
a
little
bit
of
resources.
If
you
could
interrupt
a
read
that
no
longer
needs
to
be
done
early
in
c
story
that
would
theoretically
save
resources,
so
that
would
be
good
but
interrupting
a
transit,
a
transaction
part
way
through.
That's
not
so
simple,
there's
a
point
in
a
transaction
at
which
you
have
to
finish
it.
D
D
In
the
pg
we
in
pg
we
handle
this
by
or
up
in
the
osd
code.
You
know
there
are
a
lot
of
cases
like
that
when
you
observe
that
your
predicate
is
now
false,
you
need
to
you
need
to
release
your
op
context
and
release
any
locks.
You
have
on
objects,
there
is
actual
it's
not
just.
You
drop
the
request
on
the
ground.
There's
cleanup
to
be
done.
C
C
Yeah
that
that
has
you
mean
the
approach
with
decorating
before
passing
anything
to
stay,
then.
D
D
D
D
Well,
no,
actually,
it's
it's
not
it's
not
quite,
and
this
is
the
reason,
so
it's
easy
to
indicate
where
such
a
predicate
comes
into
play.
It's
the
first,
it's
the
first
safe,
then
call
where
you
add
it
right,
but
you
need
a
way
to
cancel
it
later
and
you
need
a
way
to
indicate
which
safe
then
calls
it
applies
to
do
you
see
what
I'm
getting
at.
D
So
here's
the
thing
when
you're
building
up
one
of
these
futures,
you
could
think
of
it
as
being
really
linear
right,
it's
just
a
sequence
of
callbacks,
but
if
you
think
about
it,
they're
actually
nested
like
if
one
one
thing
that
looks
like
one
asynchronous
operation
up
at
the
pg.
C
E
B
D
To
continuations
that
actually
are
attached
in
pg
code
in
that
case,
and
it's
not
exclusive
c
store-
might
have
its
own
such
conditions
that
it
needs
to
apply
further
down
and
in
those
cases
the
correct
answer
isn't
to
completely
stop
the
task.
It's
to
re,
it's
to
return,
an
e-interrupt
error
to
pg,
because
that's
not
pg's
own
that
wouldn't
be
pg's
own
predicate.
That
would
be
c
store.
So
for
pg's
point
of
view,
this
is
actually
a
c
store
error.
C
D
D
So
I
don't
actually
think
that
this
should
live
in
aerator
it's.
It
would
be
complicated
to
do
it
that
way,
and
you
would
need
to
add
a
bunch
of
nested
structures
that
would
be
kind
of
hard
to
reason
about
and
probably
would
have
a
performance
overhead
in
the
case
where
it's
not
used,
which
is
not
ideal.
D
A
D
If
you
go,
look
at
the
osd
code,
open
pgbackend.h,
there's
an
interface
concept
called
a
blessed
context,
blessed
context.
Okay,
and
if
you
take
a
look
at
it
all
it
does,
is
it
encapsulates
the
pg
active
and
whatever
epic
change
check
that
happens
throughout
pg,
so
that
the
backend
implementations
don't
have
to
know
about
it?
That's
all
we're
talking
about
here,
we're
just
talking
about
different
ways
of
making
that
less
annoying
to
do
or
more
difficult
to
forget.
D
E
Oh
yeah,
I
think
that
makes
sense
and
I
can
try
that.