►
From YouTube: CDS G/H (Day 1) - OSD: Scrub/SnapTrim IO Prioritization
Description
https://wiki.ceph.com/Planning/CDS/CDS_Giant_and_Hammer_(Jun_2014)
24 June 2014
Ceph Developer Summit G/H
Day 1
OSD: Scrub/SnapTrim IO Prioritization
A
B
So
there
isn't
much
to
this
one.
Actually,
the
basic
problem
at
the
moment
is
that
we
have
some
backgrounds,
groove
io,
intensive
tasks
that
we
want
to
prioritize
with
respect
to
Kaitaia,
which
is
to
say
ideally,
if
you're
fine,
I
was
bursting,
then
you
shouldn't
do
any
of
this
background
stuff
when
you're
actually
serving
a
request
in
you
should
wait
until
there
isn't
anything.
However,
if
it's
not
first,
even
it
should
not
start.
So
those
are
the
two
pieces
we
want
to
balance
at
the
moment.
B
We
do
this
in
an
extremely
coarse
fashion
by
simply
exiling
all
of
the
background
tasks
to
their
own
thread,
pool
and
just
giving
them
fewer
threats
than
the
optical.
This
is
obviously
a
little
bit
less
than
ideal.
We
did
recently
add
a
patch
to
master,
at
least
that
uses
the
IO
priority
stuff
in
the
kernel.
2D
paradise
those
threads
and
that
doesn't
care
to
help,
but
I
think
in
the
long
term,
but
we
want
to
do.
B
Is
we
want
to
encapsulate
each
robin
snap
trim
task
as
well
as
tactful
as
in
item
which
we
simply
put
into
the
OSD
opera
or
queue
with
everything
else?
This
is
desirable
because
the
OSD
outwork
you
already
has
a
token
bucket
scheme
working.
Fourth,
I
initially
to
balance
recovery
requests
versus
client
requests,
but
it
would
be
revealed
to
extend
that
to
it
to
encompass
these
as
well,
but.
C
Yes,
so
I
guess
the
question
is
like
mechanically,
so
it's
it's,
it's
scrub
work
and
it's
snap
trim
work
right.
Those
are
the
two.
B
C
C
B
The
only
tricky
bit
is
determining
what
costs
and
priority
these
guys
should
have.
Historically,
we've
simply
added
yet
another
inscrutable
config
option
which
no
one
steps
correctly
and
I.
Think
we'll
start
with
that.
Then,
with
feedback
will
try
to
narrow
it
on
what
the
correct
value
should
be
yeah.
B
If
anyone
has
any
ideas
on
how
to
do
that,
we
love
to
hear
them
the
way
the
app
just
against
in
background.
The
Opera
Q
is
not
very
complicated.
You
do
on
a
priority
and
a
cost
for
anything
above
priority.
63,
it's
a
strict
priority
queue
and
anything
with
a
higher
priority
goes
first
in
strict
order.
I'm
below
63.
However,
we
process
items
based
on
have
it.
We
do
a
token
bucket
thing
where
each
item
that
gets
processed
as
its
costs
divvied
into
the
other
buckets
based
on
the
relative
priorities.
B
C
C
So
I'm,
the
first
thing
that
worries
me
is
that
all
of
these,
in
each
of
these
cases,
there's
a
bunch
of
clue
genus
that
will
that
essentially
DQ
seems
from
the
work
you
and
clears
it
up
whenever
there's
a
some
sort
of
reset
event
is
all
of
that.
Is
that
actually
going
to
get
simpler,
or
is
that
going
to
get
more
tricky
because
they
won't
I.
B
C
B
C
C
B
My
recollection
is
that
it
shards
out
the
work
items
based
on
the
PG
ref.
So
in
that
sense
we're
fine,
it's
it's.
It's
actually
queuing
a
pair
of
PG
breath
and
opera
quest
recognized.
So
now
we
do
a
pair
of
PG
ref.
Add
this
variant
type
right.
C
C
Okay,
I.
B
C
C
B
B
C
B
B
B
Actually,
if
we
scrub
that's
something
of
the
nuance,
we
want
to
deprioritize
the
part
where
we
square,
where
we
perform
the
lock
in
the
Chucky
scrub
and
then
do
every
subsequent
piece
of
that
scrub
at
super
high
priority,
and
so
between
the
time
when
we
walk
and
attending
the
unlock
everything
is.
You
have
I
already
put
the
parent,
where
we
initially
where
we
start
Lock
needs
to
have
a
high
cost
of
low
price
right,
but
well.
Well,
we
will
have
the
freedom
to
express
it
that
way,
the
Christian
okay.
So
that's
good!
I
guess.
C
B
It's
not
even
that
it's
that
this,
it's
the
problems
that
they're
lower
priority,
but
the
scheduling
decision
has
to
be
made
before
the
OS
gets
a
crack
at
it
by
the
time
the
OS
gets
any
of
this
information
it's
way
too
late.
That's
that's
my
mic.
My
concern!
It's
it's
not
that
you're,
not
passing
information!
It's
that
it's
semantically
one
layer
up!
It's
the
choice
to
do
the
locking,
rather
than
the
actual
reads
right.
C
B
B
C
B
C
Exactly
okay,
okay,
that
sounds
good
of
snap.