►
From YouTube: Ceph Crimson / SeaStor OSD 2020-10-06
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
So,
let's
start
before
that,
she
making
me
offline
that
she
cannot
make
this
system
stand
up
because
she
was
on
on
vacation
last
week
and
attended
the
to
meet
one.
Probably
it's
a
conference
held
by
bentel
and
regarding
me
I
was
on
pto
last
week
also
and
created
a
couple
cleanup
prs
and
I
just
started
reviewing
stem
care
to
add
the
capture
collection
and
I
will
also
looking
at
the
amnon's,
pi
and
runes
and
hopefully
could
allocate
enough
time
to
looking
at
the
few
hands
interrupt
to
the
future
as
well.
B
A
C
Yep
I
spent
some
time
reading
greyhounds
here.
We
should
probably
talk
about
that
a
little
bit
at
the
end
of
the
meeting
I
submitted
the
pr
that
fifo
is
looking
at
now
and
I
am
writing
a
disk
back-end
for
e-store,
so
I
can
start
doing
some
basic
performance
testing
of
the
transaction
manager
level.
That's
it.
A
Get
out
of
curiosity
sam
are
you?
Are
you
going
to
using
the
bbc
or
dbd
for
writing
to
the
disk?
Zbd
live
dbd
or
just
using
the.
C
C
I
can
use
a
library
that
emulates
it,
but
that
won't
tell
me
anything
about
performance
because
it'll
be
running
on
top
of
a
conventional
ssd,
so
in
that
sense
it
will
be
identical
to
doing
what
I'm
already
doing,
which
is
doing
rights
in
a
manner
that
is
consistent
with,
but
not
actually
limited
to
a
zone
device.
The
question
I
have,
though,
was
that
I
assumed
I
was
going
to
be
using.
I
o.
U
rig
it,
looks
like
iou
ring
support
is
not
merchant.
A
What
do
you
mean
by
by
by
using
iou
ring,
I
think
the
library
support
has
been
merged
in.
C
C
C
A
C
I
don't
particularly
want
to
write
a
live,
bio
urine
background
for
c-star
I'd,
rather
than
write
it
for
me.
C
As
far
as
I
could
tell
it,
hadn't
been
the
last
reference
I
saw
to
it
was
a
patch
from
march
and
I
did
check
their
master,
not
not
our
wretch,
which
specifically
said
that
they
omitted
the
actual
lip
io
ring
support
it's
just
a
refactor
patch,
so
I
think
they're
still
working
on
it,
but
I'd
be
happy
to
hear
otherwise
either
way.
My
guess
is
that
the
way
they're
intending
to
do
this
is
that
the
existing
interfaces
will
just
magically
start
doing
live
io.
C
I
am
very
happy
about,
so
it's
not
really
a
matter
of
urgency.
I'm
just
curious.
Yes,
I'm
probably
not
going
to
bother
with
actually
trying
the.
C
What
do
you
say:
delib,
z,
something
the
thing
that
emulates
a
zns
device
until
I
actually
have
one
simply
because
I
don't
think
it's
an
interesting
performance
benchmark
it'll
be
useful.
If
I
need
to
write
something
that
works
against
that
library,
but
until
then
it
won't.
C
C
D
Last
week
I
was,
I
submitted
the
interruptible
future
pr
here
is
this
and
right
now
I'm
trying
to
modify
the
code
and
add
some
unit
tests
and
in
detail,
explain
justice
sound
sam's
agenda.
No,
that's
all
for.
C
A
little
bit
so
initially,
I
was
a
bit
confused,
but
I
think
I
need
to
spend
some
time
reading
this
in
more
detail
to
make
sure
we
haven't
missed
anything,
but
I
think
he's
successfully
closed
all
of
the
ways
in
which
it
can
break,
but
I
do
have
this
concern,
which
is
that
it
introduces
dynamic
changes
in
behavior
to
called
methods.
C
This
is
by
design
show
how
you
refer
to
it
as
the
ost
map
gate
problem,
where,
depending
on
the
caller
to
osd
map
gate,
we
either
want
to
check
for
the
pg,
interrupter,
interruptable
or
not
or
pot,
or
perhaps
a
different
one.
I
argue
that
we
don't
want
that
to
be
variable
in
nearly
every
case.
D
So
I
think
you
mean
that
once
we
define
some
method
to
return,
interruptable
future,
then
the
then
the
continuations
in
it
will
will
have
will
be
interrupted,
am.
C
C
I
I
think
it
will
be
more
useful
that
when
you
create
an
object
of
type
interruptable
future,
whatever
template
another
particular
interrupt
type,
I
think
it
should
assert
that
there
is
an
interrupt,
an
interrupt
condition
that,
on
the
the
threat
at
the
time
when
safe
then
is
called,
in
other
words,
it's
illegal
to
call
safe,
then
without
prio,
outside
of
with
an
eruption
rapper.
C
I
think
that's
the
right
way
to
do
it
for
two
reasons.
The
first
is
that
it
makes
it
easy
by
inspection,
to
work
out
whether
something
is
interrupted
or
not.
The
second
is
that
it
makes
it
easy
to
rule
out
certain
categories
of
bugs.
It
means
that
a
particular
piece
of
code
will
always
be
interrupted,
or
it
will
never
be
sorry.
C
C
I'm
open
to
an
argument,
though,
if
there
genuinely
are
cases
where
this
would
come
up
or
we
want
it
to
be
possible
for
it
to
be
variable,
I'm
open
to
that,
but
I
also
I'm
deeply
afraid
of
bugs
where
a
piece
of
code
accidentally
stopped
having
its
interrupt
condition
attached
concretely.
What
this
usually
looks
like
is,
for
instance,
if
a
if
an
op
is
going
goes
to
sleep
on
some
resource.
C
That
is
well,
for
instance,
an
object
context
lock
within
the
osd.
During
the
interval
change
we're
actually
going
to
throw
away
that
object,
context,
it's
going
to
go
away
and
the
in-memory
state
that
represents
it
will
simply
stick
around
until
all
of
its
references
go
away,
but
we're
never
going
to
truly
release
that
lock.
C
So,
if
we're
relying
on
the
interrupt
condition
to
wake
things
up,
then,
if
we
didn't
have
that
embedded,
that
op
is
going
to
wake
up
and
continue
to
operate
as
though
the
pg
were
still
in
the
previous
interval,
it
won't
reset
itself
and
put
it
back
in
the
queue.
C
So
we'll
get
these
weird
very
difficult
to
debug
situations
where
things
were
supposed
to
reset
themselves,
but
don't-
and
I
argue
that
that
cost
is
really
high.
We
really
want
to
make
that
as
as
impossible
as
we
possibly
can.
C
But
again
I'm
open
like
if
there
are
reasons
why
we
might
want
to
do
it.
That
way,
it's
possible,
but
my
suspicion
is
that
we
probably
don't.
A
C
No,
it's
not
it's
still
not
determining
compile
time
annoyingly
the
way
joy
has
written
this
and
you
should.
You
should
read
it
because
this
is
a
large
departure
from
the
way
we
currently
do
these
these
these
things,
it's
highly
dynamic
at
the
top
of
the
call
chain.
When
we're
setting
up
the
state
for
an
I
o,
we
create
some
thread:
local
state
that
will
simply
ensure
that
every
call
to
save
them,
nested
dynamically
below
that
within
the
call
stack,
will
transparently
add
this
interruptible
condition
as
a
parameter.
C
C
We'll
need
we'll
need
the
state
added
in
otherwise.
So
it
does
save
us
a
lot
of
work.
Another
possibility
is
we
could
we
could
make
it
so
that
these
these,
this
future
wrapper
doesn't
have
a
safe
that
method
it
has
a
safe,
then
with
implicit
interruption.
C
That
way,
the
reader
at
least
has
a
has
a
has
a
hint
that
they're
not
looking
at
a
standards.
Actually,
I'm
gonna.
I
think
that's
a
good
answer
actually.
D
So
I
think
I
think
what
you're
suggesting
sam
is
that
I
I
assert
in
the
in
the
interruptible
future
in
the
interoperable
futures
continuation,
when
I
try
to
reference
an
interruption
condition
there
must
be.
There
must
be
one.
C
Sure
it's
a
little
bit
tricky
so
when
there
are
two
things
there
are
two
methods
in
play
here:
one
of
them
is
the
safe,
then
method
itself,
so
that's
called
synchronously
in
the
original
thread.
That
is
the
thread.
C
That's
setting
up
the
callback
state
that
method,
I
think,
should
assert
that,
no
matter
what
the
previous
state
should
already
have
been
set
up,
either
it's
being
called
from
the
context
of
a
top,
the
the
original,
like
the
originator
of
this
thing,
that
called
it
nested
under
with
interruption
or
it's
being
called
from
a
nested
continuation,
where
the
very
first
thing
it
did
was
reset
up
the
callback,
the
interruption,
I'm
sorry
in
either
case.
It
must
always
be
the
case
that,
when
safe
then,
with
whatever
I
called
it
safe,
then
with
implicit
interruption
is
called.
C
C
I
just
don't
think
we
should
call
it
safe,
though
I
think
it
should
be
distinct
and
it
should
have
something
that
implies
that
there's
more
going
on
with
respect
to
an
implication
to
an
interruption
than
the
user
is
aware
of.
In
other
words,
they
should
think
wow.
That's
weird!
I
should
go
read
that
code.
C
Okay,
anyway,
so
that's,
I
think,
that's
the
state
of
play
and
I
think
I,
on
balance,
this
is
a
reasonable
approach.
I
indeed
don't
actually
want
to
have
to
list
the
the
interruption
condition
for
every
single
call
to
save
them.
It'll
be
busy
it'll,
be
exactly
the
same.
Efficiency
wise,
but
it'll
be
busy
source
code
wise.
C
It's
like
it
honestly,
john
anything.
You
can
do
to
make
the
actual
implementation
easier
to
read
and
to
make
it
so
that,
like
the
nested
name,
spaces
are
a
little
less
cumbersome
and
it's
just
generally
simpler,
we'll
be
good.
We
need
it
to
do
as
little
as
possible
because
it
needs
to
do
so
much.
So
we
want
it
to
be
simple.