►
From YouTube: CDS Jewel -- RBD Journal
B
A
So
at
the
highest
level.
This
the
goal
of
this
generic
journalist
is
to
be
generic,
and
so
it
could
be
used
by
not
only
lib
rbd
but
then
in
15
in
the
future,
maybe
by
MDS
or
other
clients
as
the
need
to
I'm.
So
it's
going
to
be
based
on
the
liberate
us
api,
so
that
kind
of,
unlike
the
current
gentler
code,
it's
not
going
to
interface
directly
with
the
with
the
objector
and
also
different
from
the
current
journaling
code.
A
It's,
whereas
the
colonel
journaling
code
uses
the
striper
internally,
so
it
will
as
you
as
you,
write
data
to
the
to
the
journal.
It'll
stripe
it
across
multiple
objects,
as
as
you
keep
adding
more
and
more
entries
this
one
is.
This
design
is
going
to
splay
full
general
entries
across
n
number
of
objects.
If
you
say
that
you
have
a
given
object,
set
or
journal
object
set
within
that
set,
you
could
have
n
number
of
journal
objects
that
define
that
set,
and
just
just
to
keep
it
simple.
A
You
know,
let's
say
display
with
is
is
too
so.
Basically
what
that
means
is
that
whenever
a
client
uses
the
journal
API
to
to
submit
a
new
entry,
it's
going
to
round
robin
you
know
the
entries
back
and
forth
between
the
two
journal
objects
and
into
what
point
is,
and
at
some
point
those
journal
objects
will
get
full.
So
we've
you
can
configure
a
maximum
soft
maximum
size
for
those
journal
objects
and
the
reason
I
call
it.
A
So
suddenly,
all
your
odd
journal
entries
are,
you
know
you're
now
at
objects
901,
but
you
know
if
you're
even
object
is
still
on
object.
Number
zero
because
it
hasn't
been
filled
up
yet
and
trying
to
have
to
then
iterate
through
hundreds
of
possible
files
to
see
where
you
truly
are
during
replay
operations
didn't
seem
that
efficient
or
smart.
So
it's
a
sacrifice
potentially
that
you
could
close
it
an
active
said.
Well,
some
of
the
objects
aren't
fully
up
to
the
softmax
size
button.
A
You
know,
assuming,
on
average,
the
with
the
round
robin
everything
stays
pretty
consistent
with
with
the
size.
Then
you
should
notice,
you
know
any
truly
hot
objects
where
once
it
one
megabyte
the
other
ones,
that
you
know
the
full
object
size
or
something
like
that,
and
certainly
in
terms
of
code
implementation,
it
seemed
like
a
good
trade-off
to
make,
because
then
it
I
only
had
to
track.
A
I
want
you
to
then
actually
send
the
app
the
data
off
to
the
the
journal
journal
and
the
OS
keys
to
to
commit
it
to
disk
or
after
n
number
of
bytes
or
after
n
number
of
actual,
like
journal
entries.
You
can
also
have
it
flush
out
to
disk,
and
then
it
automatically
flushes
out
to
disk
when
it
knows
that
you've
now
exceeded
the
object
size
as
its
tracking
in
memory.
So
it
knows
well,
this
object
should
now
be
full.
A
Another
goal
of
the
of
this
new
journaling
library
is
that
it
can
support
multiple
readership
on
currently,
instead
of
the
rbd
murine
use
case.
The
door
here
being
is
that
you
could
have
one
data
center.
You
know
it's
the
active
consumer
and
writer
of
the
image,
so
you
have
some
vm.
That's
actually
writing
to
the
to
that
image
and
all
those
rights
are
being
now
journaled
out
and
then
you
kevin
to
other
data.
A
Centers
trio,
data,
centers,
doesn't
matter
they're
all
registered
consumers
of
that
journal
and
those
other
consumers
are
watching
the
journal
and
the
journal
objects
and
they're
trying
to
pick
up
and
try
to
keep
up
with
with
real-time
of
where
the
journal
is.
You
know
in
the
original
active
data
center.
A
So
now
each
client
can
have
separate
basically
commit
positions
of
where
they're
valid
to
where
they've
successfully
saved
all
their
data
to
their
local
osts,
and
another
feature
is
that
this
would
also
supports
multiple
writers,
potentially
an
RPD
use
case
example,
for
that
would
be,
let's
say
you
have
a
vm.
That's
got
five
different
rbd
disks.
You
can
have
all
five
of
those
rbd
images
journal
to
the
same
journal
so
that
now
you
have
a
semi
or
point
in
time.
Consistency
across
all
your
disks
for
that,
given
vm.
A
I'm
see
I
put
in
the
journal
like
in
the
etherpad
I
put
in
a
bunch
of
details
about
you
know
the
high-level
design.
You
know
what
the
general
header
looks
like
what
data
keeps
with
the
general
objects.
The
individual
journal
objects,
look
like
what
each
individual
journal
entry
looks
like
vanessa
is
engaged
we'll
go
through
it
here.
Unless
anyone
has
any
specific
questions,
but
before
I
move
on
to
interaction
and
interfacing
with
others,
you
can
interface
with
lid
barb
ed.
Does
anyone
have
any
questions
about
the
journal?
A
C
A
Yes,
one
keep
it
so
it's
actually
useful.
Besides
someone
decides
rbd
would
be
guys
and
I
I
mean
I,
took
some
of
the
I
checked
some
of
the
design
principles
from
the
current
MDS
journal
in
terms
of
how
to
how
there's
the
tools
that
can
help
the
current
MDS
journal
recover
from
corruption,
I
I
kind
of
blended,
some
of
those
concepts
into
this
new
design,
so
that
you
know,
if
you've
got
a
partial
corruption
of
your
journal
object,
it
can
still
scan
out
and
find
the
remaining
valid
entries
within
the
journal.
A
C
A
C
A
I
mean
you
can
get
me
on
the
commuter,
a
title
that
lets
you
go.
That's
it
again
that
this
specific
entry
is
is
invalid
or
you
know,
do
you
want
to
yank
it
or
whatever?
So
you
can
generic
tool
like
that,
but
in
terms
like
so
that
the
ceph
journal
repair
definitely
gets
into
look.
Let
me
go
apply.
I
know'd,
you
know
maps
that
were
come
from
the
journal
and
that's
obviously
a
little
more
specific
towards
the
MDS
lifestyle.
Yeah.
B
C
A
Alright,
so
moving
on
so
the
integrating
this
with
with
live
rbd,
so
the
user
side
of
our
BD,
it's
gonna
basically
result
in
a
new
rbd
feature
code.
This
will
be
starting
with
infernalis.
You
can
dynamically
enable
and
disable
certain
feature
codes
as
long
as
they
don't
muck
with
the
structure
of
the
actual
image
I
laid
out
I'm
disk,
so
you,
for
instance,
you
can
turn
off
exclusive,
locking
and
turn
it
on
object,
map
things
like
this,
so
this
would
be
another
one
of
those
dynamic
future
that
you
could
turn
on
and
turn
off.
A
However,
it's
going
to
that's
going
to
be
implemented
so
in
terms
of
all
all
mutable
I
operations,
so
your
rights
or
discounts,
all
those
things
would
be
recorded
to
the
journal.
If
you
have
the
rbd
cash
enabled,
so
though
it
can.
Basically,
as
the
operation
comes
in
to
lib
rbd,
it
will
submit
it
to
journal
and
then
it
can
basically
immediately
submit
it
back
to
the
cache
it.
A
Once
that
you
get
to
a
point
where
all
the
put
the
OSD
is
telling
you
that
now
you're
you're
right
operation,
your
discard
operation
is
now
safely
committed
to
the
OSD.
Then
you
we
can
deliver
already
able
to
go
back
and
tell
the
journaling
api
hey
that
operation
XYZ
it's
it's
now
safe.
So
we
we
know
it's
safe
and
here's
I
can
move
my
commit
point
up
to
at
this
point,
the
oldest
uncommitted
change
or
unsafe
change.
A
A
So
if
you
resize
create
a
snapshot,
remove
a
snapshot
all
those
things
we
just
need
to
be
recorded
so
that
they
could
get
playback
at
a
in
an
alternate
site
and
when
you,
if
you
have
journaling,
enabled
on
your
RVD
image
when
you
open
an
image
in
READ&WRITE
mode
for
the
first
time,
it'll
have
to
go
through
replay
mode.
If
you
clean
and
close
your
image,
there
won't
be
anything
to
replay,
X
and
Theory
here,
commit
pointer
should
be
exactly
as
the
current
head
pointer
of
the
of
the
image.
A
In
case
you
have
cash
on
I,
guess
it
wouldn't
necessarily
need
a
way
to
you
could
basically
just
submit
it
and
and
forget
about
it.
But
if
you
get
don't
have
the
cash
on
and
you
would
probably
need
to
synchronously
wait
for
all
those
things
to
properly
flush
out
before
it
returns.
Control
back
to
the
user.
C
A
I
mean
I'm,
saying
that
you'd
actually
have
to
go
back
to
have
to
track
the
completion.
It
actually
have
to
talk
the
completions
of
the
reason
you
know
the
rights
coming
back
yeah,
if
you
don't
have
the
cash
enabled
versus
right
now.
In
the
other
case,
it's
somebody
I'll
see
a
chemo
or
whatever
tracking
the
completions.