►
From YouTube: Ceph Crimson/SeaStor OSD 2020-08-12
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
last
week
I
was
working
on
the
structure
test,
technology-based
threshold
test
and
fixer,
and
I
noticed
that
the
the
store
store
detector
complaints
when
when,
when
cremation
starts,
because
it's
a
it,
was
reading
the
config
file
in
the
in
the
block
using
the
blocking
blocking
api.
So
I
changed
it
to
use
the
async
io.
Sorry,
the
asynchronized
gmail
file
rate
over
by
system
to
silence
the
warning
and
I
will
wrap
up
the
the
review.
B
I
modified
the
the
external
map3pr
according
to
sam
and
the
easy
comments
and
the
pr
is
updated
and
still
working
on
the
omap3
layout
operation.
Currently,
so
that's
all.
A
C
D
This
week
I
was,
I
was
still
working
on
the
interruptible
era
later
future
and
right
now
I
have
replaced
all
sister
future
with
the
the
aerator
future
along
the
I
o
execution
path
and
right
now
I
am
working
on
the
last
phase,
which
is
embedding
the
inter
interrupt
logic
into
aero
radio
creator
and
everything
goes
well.
I
think
I
should
be
able
to
submit
the
pr
within
the
next
several
days.
D
Yeah,
yes,
but
I'm
sorry
that
right
now
I
I
I
don't
have
the
data
in
my
hand,
I
can
send
it
in
the
email
later.
B
A
C
Oh
wait:
I
was
muted
the
whole
time.
Sorry
things,
I'm
looking
at
your
thing
right
now.
Do
you
want
to
talk
about
it
now
or
do
you
want
to
see
it.
B
C
C
C
Oh
it's
because
you
wanted
to
use
data
members
stashed
in
the
cached
extent
itself
right.
You
want
to
make
sure
it
doesn't
move
around
yeah
yeah.
C
C
Just
pick
a
magic
number
in
real
life,
we
probably
want
to
think
about
how
we
wanted
to
use
letters,
so
the
larger
in
one
sense.
C
There's
you
couldn't
create
a
sort
of
a
meta
root
which
just
contains
that
pointer
or
we
can
find
a
way
to
refactor
it,
so
it
fits
into
the
root.
That's
fine
with
me
too.
I
don't
know
it
doesn't
really
matter
to
me
feel,
in
other
words,
feel
free
to
provide
a
patch
that
changes
that
root
delta.
To
add
that
piece
of
information
as
well.
That's
totally,
okay
with
me.
C
B
C
I'm
sort
of
ambivalent
there
it
doesn't
seem
fundamentally
necessary,
but
it
also
seems
kind
of
unnecessary
to
add
this
extra
4k
extent,
whose
only
purpose
in
life
is
to
point
out
your
route.
So
yeah
both
seem.
A
B
This
this
is
the
current
implement
implementation.
When,
when
doing
a
split,
the
original
node
will
be
trimmed
and
the
splitting
node
will
be
allocated,
and
the
parent
node
will
also
be
looking
as
a
new
extent,
with
a
different
by
new.
A
B
B
C
C
C
We
don't
have
to
solve
this
now.
I
just
wanted
to
point
out
that
these
are
limitations
that
aren't
actually
solved
with
the
current
code.
It's
meant
the
code
is
left
fairly
flexible
as
to
what
outlier
actually
is.
I
think
I
left
it
64-bit.
So
we've
got
plenty
of
bits
to
work
with:
that's
not
really
a
problem.
C
We
just
have
to
decide
how
we
want
to
use
them
yeah.
It's
also
possible
that
we
go
ahead.
A
A
C
Mean
not
necessarily
it
might
be
multiple
process,
but
one
way
or
another
the
setup
system
for
crimson
will
will
ensure
that
we
make
use
of
all
of
the
cores.
If
that's
multiple,
crimson,
osds,
fine,
but
one
way
or
another,
that's
our
problem.
We
do
have
to
make
it
work.
I
will
point
out
that
one
process
per
core
probably
isn't
a
good
idea,
because
for
like
128
core
machine,
we
probably
don't
want
128
c
store
instances.
C
C
C
C
A
Yes,
I
I
have
two
two
arguments,
one
one,
I'm
not
quite
sure
regarding
to
the
120
20
28
crimson
process,
necessarily
bad
thing,
but
I
I
agree
with
you
regarding
to
the
we're
going
to
project
positioning
effects
and
devices
into
like
128.
A
Fragments
and
it's
exactly
big
pain
in
the
future.
C
C
A
C
C
So
for
that
reason
we
would
want
things
like
the
lba
tree
or
like
all
of
the
extents
associated
with
a
particular
object
or
pg.
We
would
want
to
be
able
to
quickly
and
efficiently
pick
out
of
one
store
instance
and
put
into
another
without
actually
necessarily
copying
all
of
it.
This
is
a
this
is
a
problem
we're
going
to
have.
C
C
C
That's
why
the
lba
tree
interface
has
a
way
of
asking
for
a
hint
for
which
led,
or
you
want
to
start
out,
we're
looking
for
free
space,
in
other
words,
being
said,
I'm
ambivalent
as
to
how
we
do
this
for
now,
just
because
I
think
it's
going
to
become
more
complicated
in
the
future
and
we'll
have
to
think
this
through.
So
if
we
want
to
stick
in
the
root
block
for
now
totally
okay
with
me,
I
will
point
out,
however,
that
oh
actually
is
the
owner.
C
D
C
C
C
A
So
we
can
pick
it
back
in
in
header
over
that
other
segment
right.
C
Yeah
concretely,
what
you're
going
to
do
is
you're
going
to
add
an
interface
to
transaction
manager
that
allows
you
to
set
or
update
the
logical
route
address,
and
then
the
transaction
manager
will
plug
that
through
to
the
root
block.
A
C
C
I
think
you
could
add
another
one
like
you.
You
could
have
a
logical
route
whose
only
purpose,
which
is
that,
like
a
well-known
logical
address,
whose
only
purpose
is
to
track
the
root
of
the
node
tree
or
any
other
logical
roots
we
create,
but
since
there's
only
going
to
be
one
of
them,
I'm
inclined
to
just
stick
it
in
the
root
block,
like
we
can
add
up
one
chunky
interface
to
transaction
manager
to
just
shove.
This
piece
of
information
through
it's
no
big
deal.
B
D
B
I
think
there
is
a
third
question
about
the
cache
eviction.
So
is
there
any.
C
Yeah,
that's
the
idea,
that's
what
I'm
writing
right
now.
Actually
so
the
first.
The
first
step
is:
I'm
gonna
write
dirty
block,
write
out
because
you
just
have
to
have
that.
So
you
can
trim
the
journal
that
the
actual
logic
for
doing
rewrites
will
be
identical,
then,
for
any
extent,
oh
actually
for
regular
extents.
You
could
just
evict
for
free
right,
the
only
constraint
being
that
we
can't
evict
anything.
That's
the
parent
of
a
cache
note
not
in
neo
node
sense,
the
lba
sense.
For
so
once
I
add
cash
pressure.
C
I
think
I'm
just
going
to
dump
them.
Do
you
need
some
kind
of
feedback
or
information
pinning
something
like
that.
C
C
A
C
The
corollary
to
that
is,
don't
hold
a
bunch
of
extent
references
and
definitely
don't
hold
them
after
the
transaction
is
over,
but
as
long
as
you'll
never
lose
an
extent,
the
memory
will
not
become
invalid,
while
you're
looking
at
it.
Oh
sorry
it
actually.
C
Can
you
don't
need
to
worry
about
this
too
much
it'll
just
cause
your
transaction
to
fail
if
it
happens
concurrently,
but
it
is
possible
that
another
transaction
will
invalidate
one
of
your
extents
while
you're
using
it,
but
the
cash
won't
evict
it
because
it'll
be
pinned
implicitly
by
the
fact
that
your
transaction
holds
a
reference
to
it.
C
In
other
words,
if,
if
you,
if,
if
there's
a
concurrent
transaction
going-
and
it
writes
to
one
of
the
extents
you've
read-
you
will
still
see
the
copy
of-
you
will
still
see
the
copy
of
the
extent
assuming
I've
done.
This
correctly,
you'll
still
see
the
copy
of
the
extent
you
originally
read,
but
it'll
be
invalid.
C
C
C
C
Hypothetically,
but
it
would
require
a
lot.
It
would
require
changes
to
the
transaction
manager
layer
just
because
the
reference
you're
holding
can
change
under
you.
So
you
can't
actually
hold
a
reference
to
pin
it.
We
would
need
to
add
a
separate
system
for
that
or
like
you'd.
It
would
be
more
like
mark
pinned
on
the
extent
or
something
holding
the
reference
wouldn't
be
enough,
but
let's
not
discuss
that
until
we
actually
need
it.
It's
possible
that
just
a
conventional
lru
scheme
will
just
do
the
job,
in
which
case
great.
C
B
C
C
We'll
need
to
worry
about
it
later
when
we
go
to
implement
clone
the
lba
tree
knows
what
to
do.
It
maintains
a
ref
count
in
the
lpa
node,
so
that's
all
handled
at
a
low
level.
It's
just
that
when
we
actually
go
and
implement
clone
it'll
be
something
like,
maybe
the
extent
map
itself
all
of
its
internal
trees.
C
Nodes
you'll,
just
like
both
oh
notes,
will
have
a
reference
to
the
root
of
that
with
an
incremented,
ref
count,
and
then
you'd
have
to
make
a
point
of
copying
and
decrementing
it
every
time
that
happens.
B
C
Yeah
so
let's
say
you're
we're
cloning,
an
object.
You're
you
create
a
new
o
node
for
the
new
object,
then
maybe
the
extent
map
route
you
just
point
directly
at
the
very
same
extent
map
route
and
then
you'd
increment
its
raf
count.
So
those
two
objects
share
the
same
object.
Contents,
then,
every
time
you
mutate
it
the
natural
operations
on
the
extent
map
anytime,
you
need
to
change
something
internally,
you'd
copy
it
and
index
and
then
decraft
it
we'd
have
to
go
to
some
effort
to
make
sure
this
actually
works
correctly.
C
C
Cool,
perhaps
I
shouldn't
have
called
it
incroft
and
deck
graph.
It
didn't
occur
to
me
that
that
would
collide
with
the
verbs
for
like
memory
operations,
but
that's
what
I
meant.