►
Description
https://wiki.ceph.com/Planning/CDS/CDS_Giant_and_Hammer_(Jun_2014)
25 June 2014
Ceph Developer Summit G/H
Day 2
RBD: Copy-on-read for clones in kernel RBD client
A
B
Okay,
good
morning,
everyone
I
will
introduce
accordion
raid
in
the
corner,
rb
client,
and
we
have
discussed
new
new
rbd
copyright
and
in
flavor
cds,
and
this
time
I
will
discuss
how
to
implement
it
in
kind
of
rbd
class
and,
as
we
know,
another
language
latency
will
be.
The
bottleneck
of
reading
object
not
exist
in
clone
because
it
will
reobject
from
parent.
B
B
C
Might
be
a
little
bit
refractoring
you
might
need
to
do
to
make
the
lower
level
calls
work,
but
I
think
most
all
the
changes
will
probably
just
be
restricted
to
like
those
rbd
image,
object,
requests
and
already
object,
request
functions
within
rv.c
and
right
right
now.
The
chrono
client
does
not
support
fancy
the
driving
version
two,
so
you
don't
have
to
worry
about
the
extra
striping
things
that
you
did
in
user
space,
which
is
nice.
B
C
E
B
D
Well,
I
I
don't
want
to
sort
of
backstop
the
the
fancy.
Striping
is
a
much
bigger
thing,
so
if
we
implemented
it
in
time
say
for
this
release-
and
it
works
well
not
for
this-
for
the
for
the
next
kernel
release
and
it
works
well
all
right
with
the
with
just
the
chunking
mode
that
we
have
then
we'll
emerge
it
and
that'll
have
to
deal
with
it
and
otherwise
otherwise
yeah
it's
the
other
way
around
yeah.
D
E
E
C
C
Yeah
they
still
slow
down
like
reading
their
object,
which
is
slightly
slower,
perhaps
than
reading
a
small
chunk
of
it,
but
they
wouldn't
have
to
wait
for
the
entire
write
and
that's
why
the
user
space
version
has
some
code
and
to
wait
for
all
the
requests
at
the
end
on
image
close
so
for
kernel
lvd.
It
could
just
be.
We
use
the
like
image
in
use
counter
and
I
can
increment
that
for
each
do
that
as
a
ref
count.
C
B
C
So
if
two
two
clients
access
the
same
image
with
another
doing
this
so
using
this,
this
copy
of
operation
is
actually
safe,
since
it
only
it
only
it
aborts
if
they,
if
the
object
ends
up
already
existing
when
it's
actually
run.
So
if
multiple
clients
have
them
inflate,
only
the
first
one
will
be.
We
will
be
done.
The
second
one
well,
we'll
just
return
success
without
actually
writing
anything.
B
C
D
So
you
want
to
know
how
the
data
is
is
essentially
goes
in
or
goes
out
goes
in,
while
the
while
the
there
is
a
list
of
bios
that
is
attached,
well,
not
attached,
but
there's
a
list
of
bios
and
it's
not
not
the
vfas.
It's
it
goes
through
the
bio
interface,
because
it's
a
blog
device
and
it
returns
the
data.
A
D
B
B
D
D
C
D
C
The
device
flags-
oh
right,
yeah,
those
are
used
kind
of
to
determine
whether
just
maintain
some
information
about
the
block
device
for
the
kernel.
It's
just
a,
I
guess
the
general
mechanism
there
is
just
to
to
like
determine
whether
that
the,
if,
if
it's
a
map
snapshot,
whether
that
snapshot
still
actually
exists
or
not.
B
C
C
We're
basically
deciding
which
part
of
whether,
where
the
data
is
going
to
be
stored
by
the
osd
client
at
the
below
the
rbd
driver,
so
we've
got
we
passed
down
either
you
put
put
together
or
either
add
in
pointers
to
the
bios.
If
it's
a
request
coming
from
the
block
device
directly
or
if
we're
doing
a
request
to
the
parent
image,
we'll
use
a
list
of
pages
that
just
writing
into
a
buffer
that
we've
allocated
ourselves.
D
Or,
what's
going
on,
the
page
is
basically
something
that
we
initiated
that
the
block
driver
itself
initiated
and
the
bio
is
used.
When
it's
the
client,
then
the
io
is
was
initiated
by
the
client,
so
the
block
device
was
opened
and
then
rather
written
to
or
whereas
the
page
lists
are
used
when
we
want
to
when
we
initiate
io
ourselves,
such
as
such
as
the
copy
app.