►
From YouTube: CDS Reef: Crimson
Description
The Ceph Developer Summit for Reef is a series of planning meetings around the next release and some community planning.
Schedule: https://ceph.io/en/news/blog/2022/ceph-developer-summit-reef/
A
All
right,
let's
get
started
so
welcome
to
the
crimson
cdf
session
for
2022..
I
thought
I'd
start
by
giving
a
very
brief
overview
of
where
we
are
with
quincy
and
a
few
thoughts
on
what
our
priorities
should
be
for
reef.
A
A
major
focus
of
the
last
year
has
been
on
stability
and
deployment
stuff
thanks
to
radic.
Crimson
now
has
support
in
both
rook
and
safe
and
seth
adm
for
deployment.
We
have
an
initial
stab
at
a
crimson
rados
technology
suite.
A
It's
even
got
a
limited
selection
of
the
thrashing
failure,
injection
and
all
those
good
tests
that
we've
come
to
know
and
love
with
pathology,
and
we've
done
a
lot
of
work
on
stabilizing
the
bugs
uncovered,
with
that
initial
toothology
testing,
in
particular
lots
of
refinements
to
the
way
up
ordering
works
and
improvements
to
the
watch
notify
apis.
A
A
We've
gained
moving
on
to
c
store,
which
is
where
a
lot
of
development
happened.
In
the
last
year,
we've
got
a
new
metrics
framework
and
a
set
of
metrics,
so
we
can
better
understand
how
c-store
is
behaving.
This
is
going
to
be
really
important
going
forward
as
we
improve
there
as
we
start
as
these
store
becomes
more
feature
complete
and
we
start
focusing
more
on
performance,
so
we've
got
metrics
for
the
cash
transaction
conflict
rate
a
bunch
of
stuff
in
the
lba
tree
to
help
us
understand
the
lb
allocation,
behavior,
etc.
A
It's
already
proved
very
useful
in
tracking
down
transaction
conflict
allocation
problems
due
to
incorrect,
hinting
a
lot
more
work
done
with
c-store
internals.
There
were
rewrites
to
simplify
and
approve
the
lba
tree.
Generally
speaking,
joyhound
added
support
for
placing
extents
in
non-journal
segments,
as
well
as
internal
refactoring,
to
support
multiple
devices.
A
The
conflict
detection
machinery
got
rewritten
to
use
interruptable
future.
We
added
initial
dns
support,
there's
a
zns
segment
manager
that
has
been
tested
on
an
actual
dns
device.
So
that's
good
and
we
have
some
generally
put
a
bunch
of
work
into
going
down
the
list
of
radius
api
test
coverage
that
we
didn't
that
we
didn't
have
yet
on
the
performance
side
c
store
saw
some
improvements
to
lba
hinting
and
journal
coalescing,
both
of
which
improved
performance.
A
One
key
there
we
go
so
this
brings
us
to
our
sort
of
our
top
line
summary
for
crimson
in
quincy,
which
is
that
crimson
osd
in
quincy
should
support
testing
of
rbd
workloads
without
snapshots
on
crimson
osd
in
a
single
reactor.
Configuration
with
blue
store,
cyan,
store
or
c
store
back
ends
deployed
with
rook
or
seth
adm.
A
So
moving
on
to
reef
the
biggest
things
I
see
in
reef
for
for
crimson
as
a
whole
are
multi-core
snapshots
and
scrub
scrub
is
particularly
important
because
we
won't
really
be
able
to
be
confident
in
any
other
components
without
scrub.
Working
snapshots
are
a
fairly
core
feature
that
baton's
going
to
be
working
on.
That
should
help
us
fill
out.
The
rbd
use
case
and
multicore
is
going
to
be
critical
for
just
being
able
to
make
use
of
modern
hardware
on
a
basic
level.
A
Single
core
was
useful
for
prototype,
but
that
needs
to
be
needs
to
be
addressed
for
reef
for
c-store,
there's
a
ton
that
we'll
be
working
on,
but
I
think
they
mostly
fall
into
a
couple
of
big
buckets:
further
improvements
to
multi-device
and
tiering,
particularly
with
respect
to
garbage
collection,
support
for
fast
nvme
devices
via
the
random
block
manager
and
once
again,
multi-core,
and
I
think,
we'll
sort
of
cheese.
This
initially
by
simply
running
multiple
c-store
instances
against
static
disk
partitions.
This
will
give
us
a
performance
baseline
that
we
can
use
to
evaluate
that
changes.
A
So
that
brings
us
to
what
I
think
is
the
first
sort
of
discussion
point
I
wanted
to
get
into
today.
I
know
jinx
and
you
had
added
something
to
the
schedule
for
to
discuss
gc
strategy
so
we'll
get
to
that
next,
but
before
we
get
to
there,
I've
been
working
more
on
crimson
in
the
last
two
months,
rather
than
c
store,
and
we
need.
I
I
think
it's
important
that
we
regularize
the
way
logging
works,
so
that
it
behaves
the
same
as
it
does
in
classic.
A
A
So
I
think
we
want
if
anyone
wants
to
sort
of
volunteer,
to
go
and
do
that
auditing.
That
would
be
excellent
and
finally
vstart
and
technology
log
to
different
files
in
crimson
than
they
do
in
classic.
We
log
to
osd.0.standard
out
instead
of
host.log,
and
there
are
a
few
other
differences,
and
I
think
we
want
to
eliminate
that
difference
as
well.
A
These
seem
like
minor
things,
but
as
the
wider
community
starts
to
interact
with
crimson,
we're
really
going
to
want
to
make
sure
that
everyone's
on
the
same
page
with
debugging,
especially
when
the
differences
from
classic
aren't
actually
that
important.
The
other
piece
is
that
now
that
we're
going
to
have
a
release
where
crimson
kind
of
kind
of
works
we're
going
to
want
to
make
sure
that
it
continues
working,
which
means,
I
think
we
need
to
select
a
toothology
test
to
start
with.
A
B
A
A
Sure,
that's
my
favorite,
my
my
favorite
debug
mechanism.
Ever
and
not
only
should
we
support
debug
ms
equals
one
should
turn
that
on
in
crimson.
It
should
have
the
same
format.
Every
every
character
should
be
identical
so
that
any
any
graphing
is
as
close
as
possible
to
classic.
Unless
there's
a
good
reason
to
change
it.
B
Okay,
I
see
because
you
know
there
are
some
fundamental
differences
between
the
logging
infrastructure
in
classical
and
in
sister,
even
the
number
of
debugging
message.
The
number
of
verbosity
levels
in
in
sister
there
are
in
in
classical
we
have
at
least
20
even
more
in
the
in
this
sister.
A
So
I
think,
there's
a
pretty
simple
solution
to
that:
debug,
ms,
equal
or
debug,
whatever
equals
one
gets
us
error
and
it'll
have
a
special
case
for
messenger,
because
just
because
equals
10
or
20
would
be
equal
to
debug
and
30
would
be
trace.
That's
the
convention.
We've
typically
used
in
the
osd
anyway.
A
C
A
D
Hey
sam,
this
is
so
I
have
one
question
for
the
crimson
design.
Do
we
have
any
consideration
to
cover
the
qrc
case?
I
know
from
the
early
design.
We
can
see
the
consideration
for
the
vns
that
how
about
accuracy
which
may
be
similar
but
still
have
some
difference
if
compared
to
the
ns.
A
You
you're
saying
qlc
as
in
yes
more
dense
than
tlc.
My
strategy,
for
that
is
that
it's
either
fast
enough
to
be
treated
as
a
random
block
manager
or
slow
enough
to
be
treated
as
a
segment
manager.
A
So
there
will,
it
will
be.
It
will
fall
into
the
same
bucket
as
zns,
but
we
can
have
different
back
ends
so
that
it
speaks
a
more
appropriate
command
set,
but
we'll
still
write
to
it
in
a
sequential
way.
Does
that
make
sense.
D
Yeah,
if
accuracy
is
sequential
right
for
from
good
but
for
rhythm,
it's
from
perform
very
bad
yeah.
A
D
Yeah,
similar
yeah
thanks
yeah,
so
some
another
question.
So
if
we
you
know,
if
some
customer
want
to
have
some
try
on
crimson
so
as
of
today,
what
is
our
best
suggestion?
D
You
know
if
some
customers
want
to
do
some
poc
on
crimson
to
understand
the
I
mean
the
performance
difference
that
how
they
can
can
catch
so
months
before
we
ever
see
some
share
from
from
mark
it's
mcnielsen
from
from
red
hat
team
to
share
some
performance
benchmark,
but
with
some
kind
of
hack
to
get
that
result
so
yeah.
So
the
question
is
actually.
D
If
some
customers
want
to
have
early,
I
mean
early
try
on
crimson
to
compare
what
they
can
get
so
as
of
the
latest
stability
and
at
the
latest
code
base.
What
is
your
suggestion.
A
Well,
like
I
said,
quincy
should
support
testing
rpd
on
crimson.
It
won't
be
particularly
stable
that
will
improve
over
the
course
of
this
year,
but
you
should.
I
would
suggest
that
if
you
have
customers
that
want
to
try
it,
you
work
out
or
you
do
some
testing
yourself
and
help
us
work
through
whatever
bugs
show
up
in
that
environment
and
then
give
them
the
instructions.
A
Does
that
make
sense,
yeah
yeah
got
it.
Thank
you.
It
should
work
mostly
long
enough
to
do
benchmarking,
probably
yeah,
hopefully
we'll
be
more
stable
as
we
go
through
this
year,
which
is
a
different
topic
I
forgot
to
bring
up.
Actually
is
everything
on
that,
though?
Yeah.
D
Yeah,
so
you
know
I
asked
this
before
we
did
get.
You
know.
Seven
messages
from
the
the
customer
we
to
to
to
you
know,
as
the
industry
is
moving
to
the
accuracy
instead
of
the
tlc,
so
we
did
see
more
interest
interest
from
the
field
to
see
how
crimson
can
actually
help
the
transition
from
tlc
for
to
the
currency.
I
mean.
A
For
what
it's
worth,
I
expect
c
stores
maturity
to
lag
crimson
as
a
whole,
so
that'll
be
a
little
bit
more
difficult,
but
again
it
should
work
now.
It
just
won't
be
particularly
stable
and
it'll
be
changing
rapidly
this
this
this
year,
so
any
feedback
you
can
get
us
during
that
time
will
be
really
helpful.
Speaking
of
feedback
during
this
year
there
was
another
topic
I
meant
to
bring
up
for
classic
osd
testing.
The
most
recent
release
is
usually
fine
for
people,
but
for
crimson
we
really
don't
want
people
testing.
A
D
Yeah,
this
sounds
good
sounds
good.
If
we
can
have
some
lkg,
that's
some
good
imagery
and
with
some
instructions.
So
we
can
have
more.
You
know
more
interactions
with
the
customers
who
are
willing
to
to
to
move
from
bluestar
to
the
you
know.
To
the
I
mean
to
the
crimson
yeah
stack.
A
Yeah,
that
would
be
good.
You
could
also
help
us
write
up
instructions
and
fix
bugs
too
that's
another
place.
New
contributors
could
could
help
anyway.
So
that's
something
I'm
going
to
try
to
push
for
with
the
wider
community.
I
do
not
think
that
we
are
the
only
I
don't
know
greg
and
joshua
here.
I
don't
know
if
you
guys
have
an
opinion,
but
I
I
feel
like
we're,
not
the
only
component
that
would
benefit
from
this.
D
Yeah
and
some
as
you
just
shared
so
for
for
reef
yeah,
for
this
release,
we
can
now
our
targeting
is
actually
to
get
the
rbd
walk
with
crimson
right.
A
A
A
All
right
any
other,
any
other
comments
about
this
part.
If
not
I'm
inclined
to
hand
it
off
to
yangson.
C
C
So
it
might
be
better
to
group
the
extent
of
the
same
character
and
the
similar
ages
together
because
they
tend
or
we
assume
they
they
will
have
a
similar
proper
probability
to
become
that
and
from
the
paper
there
is
a
cost
benefit
garbage
collection
policy
that
will
be
more
effective
if
we
can
achieve
that
goal
to
play
similar
extents
into
the
same
segment
for
reclaim.
C
C
The
first
fact
is
that
we
can
already
split
hot
encode
extents
into
a
different
group
of
segments,
so
it
is
just
a
configuration
and
we
can
enable
that
so
that
hot
and
cold
extent
will
be
placed
into
different
segments,
and
the
second
part
is
that
I
think
we
can
further
introduce
the
generation
to
segments.
So
that's
the
the
generation
number
n
will
mean
that
the
the
containing
extents
in
this
segment
will
are
reclaimed
by
n
times,
so
that
it
means
that
in
a
single
segment
it
can
store
extents
with
the
similar
edges.
C
Because
that's
a
similar
right,
I
think
it
will
imply
that
it
has
a
similar
age.
So
that's
that's.
This
is
a
picture
that
this,
for
example,
that
if
we
have
three
generations
and
the
two
extend
characters,
so
we
can.
We
will
have
six
groups
of
segments
so
so
so
that
each
group
will
contain
the
specific
character
of
of
either
hot
or
cold
or
the
generation
0
or
102,
so
that
each
segment
will
have
similar
characters
to
be
rewritten
or
to
to
be
reclaimed.
A
C
A
Yeah,
I
think
that's
where
I'm
getting
confused.
I
interpreted
this
as
we
in
we
begin
with
a
heuristic
prediction
as
to
whether
we
expect
it
to
be
frequently
modified
or
not,
and
then
we
adjust
later
if
we're
wrong,
but.
C
A
I
guess
I'm
not
sure
of
the
advantage
of
splitting
it
like
this.
It
seems
more
like
if
we
predict
that
metadata
segments
will
be
more
frequently
rewritten
they'll
naturally
end
up
grouped
nearer
generation,
zero.
A
B
A
A
They'll
be
low,
they'll
be
infrequently
mutated.
C
A
A
A
C
I
think
the
the
current
problem
is
that
when
we
rewrite
the
extents
we
mix,
we
tend
to
mix
all
the
different
segments
with
different
age
together.
So
if
we
only
write
extends
of
generation,
one
into
generation
two,
so
the
generation
two
will
have
similar
age.
That's
that's!
The
goal
is
to
isolated
the
different
age,
the
extent
of
different
ages.
A
A
It
eliminates
this.
This
strict
division
between
extent
types
which
gives
the
gc
more
freedom,
I'm
not
sure,
but
I
wanted
to
put
that
out
as
a
suggestion.
Basically,
I'm.
A
Written
into
a
plugable
garbage
collection
strategy-
that's
true.
A
Cool
we
may
want
to
retain
the
time
stamps
for
a
little
while,
actually,
I
think
I
think
we
should
retain
at
least
a
compile-time
flag
to
enable
them,
because
after
we've
run
a
benchmark,
it
would
be
nice
to
be
able
to
dump
a
a
histogram
of
the
ages
of
the
extents
in
all
of
the
generations.
That
will
be
one
way
we
can
evaluate
the
behavior
of
this
algorithm.
A
C
So
the
second,
the
further
idea
is
that
forge.
If,
if
we
have
the
generations,
then
we
can
have
multiple
tiers
of
devices.
C
The
concept
of
tears
is
that
each
tier
will
have
have
a
group
of
one
of
more
devices
of
the
same
type,
so
it
will
have
this
same
backend
and
the
implementations
and
the
higher
tier
generally
will
have
larger
disk
size,
a
lower
cost
and
but
lower
performance.
C
So
if
we,
if
so
the
generation
will
help
us
to
to
to
place
different
data
into
different
tiers,
because
the
the
the
more
number
the
larger
number
of
generation
also
means
that
the
the
the
data
it
will
become
more
code
and
it
it
doesn't
require
frequent
accesses,
so
it
can
be
placed
into
higher
tiers
and
because
each
tier
have
different
characters
of
access
patterns.
C
So
we
can
use
different
types
of
devices,
so
we
can
put
tier
zero
to
have
more
performance
and
and
the
more
expensive
devices
for
this
implementation
and
puts
more
and
configure
larger
and.
C
A
A
Yeah,
I
think
this
is
absolutely
or
this
is
generally
speaking,
the
way
to
go.
I
think
this.
This
looks
great
okay,.