►
From YouTube: CDS Infernalis (Day 1) -- OSD: Less Intrusive Scrub
Description
Videos from Ceph Developer Summit: Infernalis (Day 2.1)
04 March 2015
https://wiki.ceph.com/Planning/CDS/Infernalis_(Mar_2015)
A
B
B
So
finish
that
up
to
rel
one
fairly
simple,
one,
though,
is
randomizing
the
scrub
scheduling
times
to
avoid
having
scrub
waves
right
now,
when
you
create
a
pool
all
of
the
pg's
sort
of
have
the
same
scrub,
a
glass
scrub
stamp,
so
they
all
get
in
line
to
scrub.
At
the
same
time,
like
a
week
later,
this
actually
does
kind
of
even
out
over
time,
because
the
wave
will
smooth
out,
but
people
still
don't
like
it.
So
we
can
do
better
by
adding
a
uniform,
random
fuzz
factor.
B
Another
piece
is
that
we
currently
choose
to
scrub
an
entire
PG
if
the
scrote,
if
the
load
is
low
enough,
but
we
could
be
more
granular
about
this.
We
could
actually
make
the
decision
on
each
scrub
chunk
on
a
chunk
by
chunk
basis,
so
that
if
the
primary
becomes
busy
halfway
through
a
scrub
troubling
just
kind
of
stops
making
progress
for
a
while.
B
So
that's
another
option.
That'll
be
easier
to
do
once
we
have
the
unified
work
too.
Oh
yeah
piece
of
this
is
once
we've
committed
to
doing
a
scrub.
All
of
the
scrub
operations
need
to
happen
at
the
highest
priority
possible.
That
is
once
we've
committed
to
scrubbing
a
chunk
because
we're
locking
that
object
range
during
that
time.
C
B
I'm
at
the
message
priorities:
they
should
go
to
the
front
of
the
queue
so
they're
finished
quickly,
so
that
the
primary
can
no
any
objects
they
should
get
in
in
in.
In
other
words,
we
should
delay
the
scrub
until
we
decide
to
do
it,
at
which
point
we
need
to
do
it
with
the
highest
message.
Priority
possible
right.
It's
a
priority,
inversion
problem,
yeah.
C
B
That
that
component
is
about
throttling
the
choice
to
enter
the
scrub
region.
So
when,
before
we
choose
to
scrub
the
chunk,
we
will
have
paid
tokens
into
the
bucket
by
doing
a
whole
bunch
of
other
work
yeah
or
we
just
choose
to
not
do
it
if
there's
other
stuff
with
the
queue
something
like
like
that,
in
other
words
that
so
once
once
after
we've
we've
already
done
the
throttling
part,
we
decided
that
now
is
the
time
for
the
scrub.
At
that
point,
we
choose
to
impact
iio
as
much
as
possible.
Well
and.
D
C
Take
that
I
think
that
needs
to
be
that
decision,
though,
because
there
are
lots
of
cases
where
you'd
rather
have
the
ninety-nine
percent
of
the
time
have
a
low
impact
and,
in
the
one
percent
of
the
time,
have
a
longer
tail
right
and
suffer
the
priority
inversion,
because
reality
is
that
we're
never
going
to
perfectly
be
able
to
part
dos
there's
always
going
to
be
some
cost
to
doing
this
code.
Yeah,
okay,.
B
Right
off,
I
mean
okay,
so
well
yeah.
The
important
thing,
though,
is
that
we
should
make
that
the
load
decision
at
each
chunk
and
not
for
the
whole
via
yeah
that
one
it
means
that
scrub
might
not
make
progress
for
a
while,
but
that's
just
the
way
it
goes
so
a
in
other
words,
a
PG
might
be
scrubbing
for
a
very
long
time,
if
it
happens
that
we're
running
in
the
only
at
low
low
low
load,
guzzling
period
and
load
habit,
and
that
would
mean
okay.
That
would
be
as
expected.
It.
A
B
C
Mean
assuming
that
we
did
all
the
prioritization
that
we
wanted
if
a
scrub
happens
and
it's
basically
just
pegging
the
disk
that
random
I/o
that
comes
along
is
going
to
be.
You
know.
Every
single,
random
I
hope
that
comes
along
is
going
to
be
impacted,
negative
Ailin
detected,
whereas
if
you're
sort
of
trickling
through
it
only
ten
percent
of
disk
load,
then
you
know
ninety
percent
of
the
iOS
will
be
unaffected
and
ten
percent
well.
C
B
Yeah
there's
a
lot
of
overhead
associated
with
with
scheduling
a
scrub
trunk,
because
we
do
some
work
to
interleave
the
scrub
message.
Passing
with
what
do
we
yeah,
because
we
embed
a
sort
of
the
last
update
thing
in
the
message
and
then
the
replica
receives
and
then
waits
until
that
exact
one
applies,
and
that
immediately
does
this
describe
and
returns
so
the
rub:
do
the
primary
doesn't
have
to
wait
for
the
messages?
C
C
D
C
B
C
And
somnath
asks
for
scrubbing
recovery.
Is
there
a
way
to
get
predictable
gos?
There
are
many
small
things
we
can
do
to
improve
it.
It
isn't
it
more
meaningful
to
let
that
long
with
this
carb
improvement,
I
think
we're
it's
yes
and
no,
I
mean
they're
like
lots
of
small
problems
we
have
to
solve,
but
the
most
central
problem,
I
think,
is
this
unified
doing
very
smart
of
privatization.
Just
part
of
this
and.