►
From YouTube: 2020-02-25 :: Ceph Crimson Meeting
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
D
C
C
D
C
C
D
C
D
Important
actually,
because
they
test
really
really
difficult
to
reproduce
edge
cases
in
the
way
logs
are
merged,
but
that's
like
if
you
go
read
that
code
you'll
see
why
it
has
seen
theater
tests
it
does.
There
is
a
lot
of
fiddly
bits
with
exactly
which
log
entries
are
just
art
are
detected,
is
missing
and
what
their
versions
are,
and
logic
is
very
faintly.
Fortunately,
that
logic
does
not
require
a
toastie.
D
It's
restrictive,
eg
log
class,
but
which
is
the
thing
we
did
when
we
did
the
hearing
state
machine
refactor
back
2012,
but
we
weren't
able
to
hoist
the
rest
of
the
recovery
code
out
the
same
way,
though,
that
stuff
don't
have
dependencies
back
on
a
real
OS
OSD.
It's
gonna
be
very,
very
hard
to
construct
unit
tests.
So,
although,
if
you
can
by
all
means
like
if
you
could
find
a
way
to
like
build
out
the
PG
scanning
logic,
so
that
it's
both
non-trivial
and
well
I
mean
they're
they're,
they're
scripts,
but
you'll
notice.
D
Definitely
should
should
it
strive
to
do
that
as
best
you
can.
I
will
point
out
that
the
scanning
code
there's
very
little
to
it.
Like
you
get
in
a
message
and
then
you
basically
call
the
corresponding
officer
method.
It's
not
a
lot
else
going
on.
It's
really
just
a
message.
The
backflow
code
of
the
primary.
E
C
How
to
do
this
sector
just
does
the
key
lookout
responsible
for
for
message
handling,
but
in
case
of
PD
scanning?
Okay,
it's
quite
simple,
but
still
this
the
scanning
code
could
be
student
in
some
kind
of
scanner
component.
That
will
be
just
that
would
require
just
some
blue
ink
or
for
message
handling
with
2
OSD,
but
the
sky
layer
itself.
I.
Think
you
that
quantitative.
C
B
F
D
A
C
D
No
I'm
dead
serious
right
now
there
there
is
it's
more
important
to
get
this
merged
than
to
solve
the
exact
details
of
what
an
official
build,
looks
looks
like
so
for
now
it's
part
of
the
only
build
we
have,
which
is
the
death
build
or
the
production
builder
or
whatever
I'm
saying
it's
not
that
interesting
to
work
out
whether
we're
gonna
support
it
in
the
future.
For
now,
it's
enough
to
say
well,
this
is
what
we're
building-
and
this
is.
This
is
the
build
that
says,
we're
that
performance
numbers
work
and
that's.
D
D
D
F
Needed
to
have
some
little
patch
from
a
sister
because
equal
to
one,
we
have
to
make
a
set
up
the
qfo
as
I'm
here
co2.
What
so
you
need
changes,
some
sister
code
and
the
further
release
version
and
sister
build
used.
Sister,
allocator
and
I
try
to
enlarge
the
sister
applicator,
some
memory
allocation.
F
It
passed
the
first
occasion
fielded
by
this
in
the
later
rescue
has
some
error:
I'm,
not
sure
if
in
the
POSIX
right
that
it
can
yield
sister
allocate
her.
So
I
would
want
to
check
with
sister
gas
if
in
the
POSIX
right,
environment,
environment
and
the
kind,
if
we
can
use
the
sister
allocator
and
if
they
decide
yes,
it
it
sure,
and
then
I
will
debugging
on
nature,
so
that
later
alligator
sees
you,
but
the
turn
to
the
default.
F
F
Lab
lab
seen
every
know
that
not
at
the
sister
is
owen
new
operator
news
and
the
new.
The
scenario
sees
his
own
new
operator.
So
it's
different.
It's
all
controlled
by
the
sister,
but
that's
a
failure
happened
in
the
blue
star
posix
party,
so
in
large
the
number
there
I
found
some
in
some
fixed
number
hard
code
number
in
the
sister,
but
I
still
had
error
later.
F
When
the
code
running
when
I
do
the
the
right,
tester
and
I
think
that
the
Firth
at
the
beginning
there,
where
a
day
allocate
memory
allocation
for
the
rocks
TV,
then
that
pastor
finally
asked
you
had
ever
so,
and
the
first
I
want
to
make
sure
if
the
ailing
word
can
use.
There's
a
sea
star,
I,
look
at
her.
F
D
No
we're
a
long
way
off
I
hope
to
have
something
benchmark,
able
at
a
really
simple
level,
just
the
LBA
component
within
the
next
I
think.
Six
weeks
ago,
I
said
within
the
next
six
weeks,
so
I
say
again
within
the
next
six
weeks,
hopefully
sooner
sorry
but
yeah.
We're
writing
this
from
scratch.
Blue
store
started
with
a
lot
of
stuff
that
this
doesn't
start
with.
We
have
to
write
it
from
scratch.
Okay,.
F
A
A
D
A
I'll
get
your
PR
tests
to
do
so
by
the
end
of
this
week
by
the
way,
because
it
changes
the
year
15
piggy,
lock
an
interface
so
I'm
I'm
concerned
before
we
can
get
emerged
before
October
to
get
it
out
the
door,
so
I
I
would
prefer
postpone
it
until
after
October
is
either
released.
Do
we
have
more
time
to
hammer
on
the
change.
G
E
A
E
E
A
E
E
E
E
A
E
A
E
D
A
A
D
A
D
A
A
D
D
A
D
So,
if
I'm,
remembering
correctly,
all
that
is,
is
it
allows
the
same
messenger
to
show
up
on
more
than
one
to
address,
so
if
you
send
a
bath
to
any
of
them,
it's
the
same
thing.
We
need
an
entirely
different
thing.
We
need
basically
one
messenger
per
core
and
I
don't
mean
one
messenger.
Procore
has
distinct
from
multiple
captions.
What
I
mean
is
the
client
needs
to
know
the
difference,
the
client
and
when
it
when
it,
when
it,
when
it
runs,
crush
on
an
object,
it's
gonna
get
back
a
PG.
D
Then
it's
gonna
get
back
in
OSD
that
it
needs
to
send
the
message
to
that's
what
it
does
now
and
right
now.
It'll
pick
whatever
of
those
addresses
is
the
right
one
to
send
it
to
based
on
its
position
in
the
network.
However,
what
we
needed
to
do
is
do
one
more.
We
needed
to
say:
okay,
there
are
ten
ports
exposed
for
the
so
SD
and
I
am
actually
talking
to
PG
2
point
2
to
point
to
is
on
shard
3
I
need
to
talk
to
sure
3
that
doesn't
exist.
Yes,.
D
E
D
D
And
that
has
additional
really
complicated
ramifications
like,
for
instance,
what
happens
when
PG
splits
happen?
Do
you
have
to
move
PG
s
between
shards?
In
that
case
you
wouldn't
you
you
would
actually
or
you
might
get
unbalanced
charts,
which
we
really
bad
so
I
think
in
the
short
term,
we
should
actually
think
about
how
do
we
efficiently
hand
off
connections
between
cores
I?
D
Think
that's
the
short
term
solution
and
we're
gonna
need
to
be
able
to
do
it
for
backwards
compatibility
anyway,
because
old
clients
are
gonna,
won't
won't
know
about
this
and
I
think,
while
optimally
yeah,
we
wouldn't
do
this.
We
have
to
remember
we're
talking
about
one
thread
switch
compared
to
the
like
eight
minimum
in
clásicos
OSD.
A
D
Moved
from
from
there
and
there
there
are
other
little
things
we
can
do
too
I'm,
even
without
changing
the
protocol
we
could,
for
instance,
we
could
have
them.
We
could
change
the
v2
protocol
a
little
bit
to
allow
you
to
publish
more
than
one
port
and
every
time
you
get
a
message
if
it
was
to
the
wrong
port,
you
could
say:
okay,
I'm
handling
it,
but
by
the
way
for
all
future
messages
on
this
PG,
please
redirect
to
the
other
port.