►
From YouTube: Ceph Developer Summit Quincy: RADOS Follow-up
A
A
A
A
Those
required
will
be
made
by
the
dashboard
team
and
we
figure
out
what
needs
to
be
done
there
so
I'll
skip
that
next.
Also,
the
crash
telemetry
panel
stuff
lots
of
improvements
mentioned
in
the
ether
pad,
nothing
particular
I
mean
we
have
one
card
here
about
mapping,
device
errors
and
osd
crashes
factor
devices.
That's
a
radius
card,
that's
been
there,
but
I
don't
think,
there's
anything
specific
that
we
want
to
create
there
as
well.
A
So
moving
on
to
the
next
item,
which
is
about
blue
store
or
split
cash
improvements,
we
did
not
go
over
this
in
detail
in
the
last
cdm
session,
because
the
availability
of
some
of
the
blue
store
books,
but
there's
a
detailed
document
about
how
we
want
to
make
these
improvements
and
we'll
probably
go
over
this
in
a
performance
call
or
something
for
now
we
have
added.
This
is
in
this
link
to
the
either
pad
is
already
there.
A
A
A
A
A
In
general,
I
feel
we
have
cards
that
capture
some
of
the
improvements
that
are
mentioned
in
this,
but
I
guess
the
idea
will
be
some
of
the
cards
that
are
already.
There
are
more
like
short-term
things
that
we
are
aiming
to
get
done
in
quincy.
As
we
start
taking
things
as
done,
we
will
be
able
to
make
more
cards
that
we
can
probably
target
for
quincy,
or
maybe
even
later,
that
that
was
the
general
approach
for
this.
A
A
D
A
B
E
A
A
A
Like
one
is
this,
we
decided
that
we
will
have
separate
auto
profiles
and
users
can
just
select
which
profile
they
want
to
select
based
on
what
kind
of
workloads
they
are
running
or
what
the
state
of
the
cluster
is,
so
that
this
card
addresses
that
bit
and
and
yeah
this.
This
is
the
main
thing.
This
is
what
we
attempted
to
address
in
specific.
There
are
some
rough
edges,
so
it's
still
marked
frequency.
B
A
A
A
So
that
address
is
one
part
of
the
problem,
but
I
guess
the
other
main
issue
was
that
we
decided
that
we
do
not
want
to
store
all
these
low
request
messages
in
the
cluster
log
and
probably
just
direct
it
to
the
manager
log
and
not
store
everything
I
have
like.
You
know,
n
number
of
updates
that
we
store
so
have
got
your
in
yours,
so
this
addresses
that
problem.
A
D
D
A
A
A
That
brings
us
to
this
last
item
here,
automated
auth
key
rotation.
We
had
a
detailed
discussion
about
this.
Unfortunately,
the
the
source
from
where
this
requirement
came
in
there
is
lack
of
clarity
on
what
is
actually
needed,
so
we
hope
to
get
more
clarity
from
them,
maybe
in
a
month
or
so.
But
if
we
do
get
clarity
on
that,
it
would
be
a
nice
to
have
featured
in
quincy,
but
I
I
don't
have
any
more
details
at
the
moment,
but
we
have
a
card
for
it
and.
A
A
A
Then
we've
got
so:
we've
got
a
few
items
related
to
a
qos.
This
is
something
we
did
not
discuss,
particularly
at
cds,
but
we
have
a
lot
of
clarity
around
what
we
want
to
do
and
what
is
done.
So
there
is
not
trimming
scrub
and
pg
deletion
that
we
want
to
address
next,
as
some
of
the
background
activities
that
m
clock
will
also
prioritize.
A
So
if
we
get
these
done,
we
can
essentially
I
I
think
this
covers
everything
we
don't
require
any
of
those
manual
sleep
stuff
that
we
have
for
all
of
these
background
operations
and
we've
been
snap
running,
I
don't
think
we've
started
work
on,
but
pg
deletion
and
scrub.
We
have
ongoing
work
on
that.
D
A
Perfect-
and
I
would
like
to
also
mention
that
the
aim
with
quincy
is
to
default
to
m
clock
scheduler.
I
already
have
a
pr
out
for
that.
There
are
some
testing
issues
that
came
up,
so
we
might
need
to
adjust
some
tests
and
stuff,
but
if
everything
goes
well,
we
will
go
ahead
with
that
change.
So
quincy
will
default
to
n
clock
scheduler
versus
wp
q,
which
is
the
default
at
the
moment.
A
Then,
apart
from
the
background
activity
stuff,
we
also
have
automate
baseline
measurements,
so
currently
m
clock
or
the
m
clock.
Scheduler
requires
us
to
feed
in
some
data
or
some
information
about
cluster
performance
or
throughput,
and
that's
a
manual
step
at
this
moment,
and
we
have
some
default
values
but
which
may
not
hold
for
different
kinds
of
clusters.
A
A
A
One
is
cylinder
review,
so
we
have
the
docs
part
of
it,
but
it'd
be
really
nice
to
have
it
as
a
part
of
the
dashboard
and
that's
one
thing
I
discussed
with
the
dashboard
team
in
cds
is
currently
what
we
have
is
m
clock
just
has
some
profiles.
The
default
profile
is
going
to
prioritize
client,
I
o,
but
it
would
be
nice
to
have
give
users
the
ability
to
just
change
that
profile
in
the
dashboard
itself.
A
B
A
A
So
the
next
item
is
just
a
clean
up
item,
but
I
think
it's
again
useful.
The
idea
is
that
we
have
a
whole
bunch
of
asserts
in
the
code
which
are
multi-condition
asserts.
So
from
debugging
point
of
view,
it's
very
difficult
to
understand.
It's
not
obvious,
let's
just
say
that
which
assert
was
hit.
So
there
is
some
extra
work
that
developers
need
to
do
be
able
to
identify
which
assert
would
hit
or
the
bug
is
about.
B
C
B
It
might
depend
on
where
we
show
it.
I'm
not
sure
if
we've
put
much
thought
into
that,
like
my
first
guess
would
be
the
device
ls
screen
that
lists
your
devices
should
show
like
error
count
or
air
history
or
something
I
don't
know,
and
I
could
show
crashes
too
if
we
wanted
to
do
that,
but
it
doesn't
map
as
cleanly
to
device
as
it
does
to
a
demon.
So
that
may
or
may
not
make
sense.
C
B
B
C
A
B
A
A
There
are
a
whole
a
lot
of
other
items
like
some
marked
with
small,
which
be
nice
for
somebody
who
wants
to
get
introduced
to
raiders
or
like
even
ceph
and
start
picking
up,
but
we
don't
really
have
a
target
in
mind
for
them.
So
I'm
not
going
to
go
through
all
of
these
items,
I'm
going
to
move
to
store,
monitor
and
manager.
A
So
for
bluestone
we
discussed
the
split
cache
improvements.
There
are
a
couple:
others
one
is
about
make
assets
unique
per
return
value
so
currently,
when
we
assert
in
some
places
in
blue
store,
we
just
assert,
but
it's
not
clear
why
we
assert
it
as
in
the
return
value,
is
not
clear
whether
it
was
out
of
space
or
it
was
some
sort
of
eio
making
them
explicit
again
helps
with
debug
ability
in
general.
So
this
is
again
marked
with
small
for
blue
store.
A
F
A
A
A
A
A
Yeah,
essentially,
when
you
at
what
point
do
you
do,
you
know
make
pgs
inactive
think
just
having
to
know
how
many
of
them
are
in
in
what
state,
just
the
breakup
of
how
bad
or
how
much
time
a
pg
would
need
to
recover
break
up
of
that,
making
that
more
obvious
to
the
user.
Currently,
it's
just
overall
degradedness
of
the
cluster
that
we
show
so
this
this
is
where
this
comes
from.
A
B
A
A
A
B
A
A
B
A
A
A
Doesn't
mean
any
more
discussion
here
next,
we've
gotten
this
item
from,
and
this
is
also
spelled
over
from
pacific.
The
implementation
was
not
that
trivial.
The
idea
is
to
be
able
to
use
the
actual
osd
utilization
for
balancing
pgs
by
the
upma
balancer
versus.
Currently,
what
we
use
is
the
number
of
pg's
per
usd
there's.
There's
a
lot
of
discussion.
We've
done
around
this.
We
all
think
this
is
a
good
idea
getting
it
in.
That
is
a
left.
A
A
This
is
another
thing
we
all
agree
is
yeah,
so
next
one
is
also
something
that
fits
in
like
a
short-term
improvement
of
our
manager.
Scalability
also
fits
in
with
some
of
the
trimming
work
we
did
with
making
trimming
more
dynamic,
so
this
manager's
tax
period
is
again
a
static
value.
The
idea
is
to
be
able
to
dynamically
change
this,
based
on
what
the
ingest
rate
is
for
the
manager
and
brad
has
been
working
on
this.
A
B
A
B
B
I
would
put
this
in
the
whole
bucket
of
discussion
about
how
we
need
to
look
at
the
object
or
implementation
itself,
as
well
as
the
messenger
and
reactor
frameworks,
not
sure
this
came
up
a
little
bit
during
cds,
but
it's
not
it's
not
clear
that
it's.
It's
likely
that
there's
more
work
that
needs
to
be
done.
The
object
or
itself
would
be
to
actually
run
in
the
reactor
framework
right
now
it
uses
the
seo
function,
calls
but
doesn't
actually
it
still
uses
that
same
red
architecture.