►
From YouTube: Ceph User + Dev Meeting 2022-05-04
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
I
think
we
can
kick
it
off
and
let
me
officially
get
this
cdm
off
so
hello
and
welcome
everyone
to
cdm
for
the
month
of
may.
Today
we
have
a
light
agenda,
I
would
say
we
have
one
topic
and
martin
is
already
here
before
time.
I
would
say
so.
I
think
I'm
gonna
hand
it
over
to
you.
Martin.
B
B
These
nvme
devices
have
the
capability
to
do
online
compression,
so
they
basically
provide
a
large
space
like
22
terabyte
of
logical
blocks,
but
this
is
backed
by
only
9.6
terabyte
of
physical
storage
space,
so
their
model.
The
usage
model
is
very
similar,
similar
to
the
vdo
device
that
is
already
supported
within
seth.
B
So
the
video
device
has
the
same
kind
of
usage
model
and
it
uses
side
channel
to
report
back
to
basically
the
top
layer
of
ceph,
what
the
actual
usage
of
physical
blocks
in
the
devices
to
allow
early
warning
of,
basically
disk
fall,
which
is
not
directly
visible
from
the
usage
of
the
logical
blocks
in
order
to
support
our
device.
B
Actually,
I
first
experimented
to
put
in
a
code
basically
just
next
to
the
video
component
into
self,
but
this
didn't
look
right
for
me
because
it
would
just
add
our
device.
So
I
changed
the
strategy
by
adding
a
plugin
system
for
this.
I
basically
copied
the
the
base
structure
of
the
erasure
code,
plugin
system
into
basically
a
new
plugin
system.
That
is
basically
in
a
neighboring
directory.
B
It
is
yeah.
I
call
this
thing
x,
block
device
axtblkdev
and
it's
basically
loads
plugins
that
have
an
interface
that
provides
all
these
side
channels
that
actually
the
vdo
uses
to
provide
physical
block
utilization
up
to
the
sap
layers,
and
I
took
the
vdo
device
and
basically
created
one
first
plugin
to
basically
basically
demonstrate
how
this
plug-in
system
works,
have
a
reference
implementation,
and
this
allows
now
us
to
later
add
the
plug-in
for
fcm
device.
B
Yeah,
that's
our
storage
device.
The
problem
is
right.
Now
the
api
for
our
device
is
still
vendor-specific
and
I'm
not
allowed
to
basically
put
it
open,
but
this
plug-in
approach
basically
would
allow
us
to
basically
ship
a
plugin
to
any
kind
of
customer
who
uses
our
device
or
even
us,
using
the
device
in
our
ibm
cloud
and
later
on.
B
I
hope
that
in
the
very
near
future,
we
actually
get
the
green
light
to
to
open
up
the
interface
to
our
fcm
device
that
allows
the
access
to
the
physical
storage
state
of
the
device
so
that
we
can
actually
put
this
plugin
also
in
the
base
cell
database.
B
One
is
the
actual
plug-in
system
with
the
vdo
device
or
video
device
plug-in
and
the
other
one
is
actually
a
feature
that
we
need
for
our
specific
device,
which
is
a
a
commit
that
enables
the
setting
of
the
keep
caps
flag
in
linux,
and
this
keep
caps
flags
maintains
the
capability
set
across
a
set
uid
system
called.
So
when
you
basically
switch
from
root
to
the
saf
user,
you
can
keep
the
permitted
capability
set
that
would
allow
later
on
a
plug-in
device
or
any
device
drivers
to
activate
capabilities
that
it
needs.
B
So,
for
example,
we
need
nvme
passthrough,
our
basically
query
commands.
They
are
lock
queries
for
that.
We
need
sys
admin
capabilities
and
our
plugin,
then
just
flips
in
the
effective
capability
set
the
sys
admin
on
when
we
read
the
state
and
then
turns
it
back
off,
so
that
actually
no
other
part
of
the
set
code
can
access
this
capability.
B
Unless
it's
explicitly
aware
of
that,
this
setting
of
the
of
the
keep
caps
flag
is
also
gated
by
a
configuration
flag
that
is
by
default
false.
So
you
would
need
to
actually
enable
that
flag
in
order
to
keep
this
capability
set
active
across
set
uid
codes
yeah,
I
think
that's
basically
it
so.
This
structure
of
the
other
commit
that
actually
implements
the
the
the
actual
plugin
system
consists
out
of,
of
course,
some
cmake.
B
So
I
added
a
subdirectory
where
the
actual
plugin
system
is
the
sub
directory
is
xblock
device.
So
I
had
to
add
c
make
files
add
in
the
base
c
mac
of
this
source
directory
the
inclusion
of
that
directory.
B
B
What
else
the
kernel
device
is
actually
that
the
part
that
caused
this
interface,
so
I
basically
changed
the
other
chords
to
the
vdo
components
by
the
calls
across
the
registered
plug-ins
in
the
plug-in
system.
So
the
plug-in
system
provides
basically
a
plug-in
registry
via
configuration
strings.
B
This
set
of
plugins
can
be
specified
that
gets
pre-loaded
on
actually
osd
start
time
and
then,
when
a
device
is
opened,
we
go
over
the
set
of
of
plugins
and
find
the
plug-in
that
actually
can
control
that
device,
and
that
is
then
registered
with
this
kernel
device
structure
and
then
later
on,
when
utilizations
are
queried,
we
call
the
interface
of
the
plugin.
B
That
is
that
part.
What
else
we
have.
B
Yeah
and
yeah,
then
there's
the
plugin
system
itself
plug-ins
and
a
the
the
preload
of
the
plugins
in
global
init,
and
I
think
that's
basically
it.
A
Yeah,
I
guess
a
little
bit
of
background
for
everybody
who's
there
on
the
call
we
discussed
this
briefly
at
the
cdes
session
for
radius
and
everybody
thought
it
was
a
good
idea,
but
I
think
at
that
time
your
pr
wasn't
structured
in
this
way.
I
think
it's
very
well
structured
at
the
moment
for
review.
So
that's
it's
kind
of
a
follow-up
of
that
and
at
the
moment
so
have
you
been
able
to.
A
I
know
there's
this
in
the
existing
video
as
your
current
user
of
the
plugin
right,
so
the
first
plugin
that
you
use
have
you
been
able
to
test
it
at
any
any
level.
B
A
B
I
have
not
tested
it,
so
I'm
actually
not
the
way.
I
I
know
that
the
video
is
a
linux
module,
but
I
don't,
I
think
it's
not
a
part
of
the
regular
distribution.
I
think
it's
owned
by.
I
don't
know
red
hat.
I
think
the
video
technology-
I
I
don't.
I
don't
know
if
it's
open
source
and
available
for
everyone.
A
Yeah,
I
think
I
was
looking
through
the
original
implementation
where
sage
actually
added
it
and
I
was
seeing
how
he
tested
it
and
there's
some
hints
I
got
from
there,
but
I'm
not
sure
if
those
are
still
valid-
and
this
is
the
pr
I'm
looking
at
this
might
be
a
good
reference
to
look
at,
but
I'm
not
sure
all
the
details
will
hold
true.
A
C
C
A
C
C
I
haven't
I'm
just
skimming
through
this
now.
Certainly
the
shape
of
this
interface
looks
right
to
me.
I
don't
think,
there's
any
problem
there,
I'm
a
little
concerned
about
the
keep
caps,
partly
just
because
I'm
not
real
familiar
with
like
the
details
of
how
the
security
model
works,
but
I
mean
we
we
stopped
running
as
root
on
purpose
and
and
just
sort
of
keeping
all
our
root
capabilities.
B
So
the
idea
of
the
keep
caps
I
mean
is
a
little
bit
more
complicated
you
basically
in
order
to
normally
you
don't
really
use
the
keep
caps.
You
set
a
set
of
capability
flags
on
an
executable
when
that
that
one
is
loaded
and
the
user
itself
has
a
set
of
capability,
then
basically,
the
the
the
end
of
that
set
is
what
becomes
available
and
that
application
at
that
point
needs
to
be
aware
of
capability
and
set
these
individually.
B
The
keycaps
basically
takes
a
broad
stroke.
It's
really
when
you
switch
from
route
to
something
else,
to
keep
basically
the
flag
set.
You
can
actually
also
kill
individual
flags
so
that
after
you
switch
route
yeah,
I
think
that
there
are
more
than
30
different
flags
that
affect
basically
any
some
kind
of
of
root
capabilities.
For
example,
there's
one
specific
for
accessing
raw
sockets,
or
so
you
can
do
a
ping,
for
example.
So
there
is
a
fine
granularity.
The
problem
is
so
you
could.
B
Basically,
I
could
extend
this
patch
to
have
more
configuration
options
so
where
you
could
actually
specify
hey,
I
want
to
keep
capabilities,
but
I
want
of
these
30
plus
capabilities,
only
that
one
to
survive
the
switch
and
then
it
would
also
only
survive
basically
in
this
permitted
set,
which
does
not
still
does
not
enable
you
to
do
system
calls.
You
still
have
to
then
do
specific
capability
calls
to
activate
they
put
it
in
the
effective
set,
and
then
you
can
use
this
capability.
B
C
C
B
Yes,
yes,
you,
you
can
actually
specify
so
the
way
it
works.
The
kid
caps
basically
says
the
the
the
permitted
set
from
the
user
id
that
that
exists.
At
the
point
of
time,
when
you
set
the
key
caps
will
be
maintained
over
the
next
suid
call
right,
but
you
can
flip
all
of
them
off.
You
can
never
flip
them
on.
You
can
only
flip
these
effective
bits
off,
there's
no
way
to
flip
them
on.
B
D
C
B
D
B
But
I
have
to
make
a
disclaimer
here,
the
the
envy
I
mean
the
capability
system
itself
is
not
that
great.
In
the
respect
that
this,
the
individual
capital
e,
that
exists
have
been
a
patchwork.
I
don't
know
if
you
read
about
that,
they
have
been
added
basically
on
it
on
need
basis
and
all
the
capability
for
which
not
a
specific
class
has
been
found.
They
have
been
all
swept
into
a
capability
bit
that
is
called
sys
admin.
B
D
D
B
D
B
The
third
point
you
made
a
comment:
basically,
there
are
two
options
to
implemented:
one
have
an
option
in
the
option:
files
where
you
can
specify
hey.
I
need
that
one
or
provide
each
of
the
plugins
with
with
basically,
let's
say,
a
query
function
where
you
can
return
a
required
bit
set
right.
That
would
automate
that
system.
B
B
Okay,
okay,
I
can
do
that.
I
mean
this.
This
should
be
not
too
difficult,
just
add
a
function
that
returns
a
set
yeah,
but
that
also
actually
means
that.
So
there
are
there's
a
library
that
libcaps
library
that
actually
manage
all
of
that
that
basically
can
create,
sets
and
store.
It
provides
a
structure
for
that
and
calls
the
kernel
functions
at
that
point
of
time.
I
would
actually
need
the
lid
caps
be
part
of
the
seth
dependencies
set
right.
You
and
nobody
gets
upset.
If
I
add
one
more
room.
B
A
B
A
B
A
B
A
Yeah
we
have
bare
metal
nodes,
we
don't
use
vms.
C
B
B
A
And
any
guess
I
don't
think
we
should
stress
over
that.
I
guess
the
next
step
would
be
to
get
some
reviews
and
stuff
going
and
if
you're
able
to
provide
more
testing
details,
that'll
be
great
as
well.
Okay,
take
this
forward.
Okay,.
A
C
Well,
I
did
I'd,
ask
some
questions
that
I
mentioned
in
the
the
replanting
session,
so
my
understanding
is
that,
like
I
pointed
out,
the
vdo
integration
is
kind
of
kind
of
weird
in
terms
of
how
it
looks
to
you
know
the
upper
layers
of
the
cluster,
where
it
doesn't
understand
that
these,
the
you
know
the
space
sort
of
doesn't
really
exist
and
in
terms
of
balancing
and
stuff
is
that
it
sounded
like
that.
Wasn't
something
you
were
too
worried
about
your
initial
deployment.
But
is
it?
C
B
That's
a
good
question,
I
mean
in
theory
it
would
be
nice,
for
example,
to
get
compression
ratios,
propagated
up
and
display
them
and
so
on,
but
all
of
this
doesn't
exist
in
seth,
right
yeah.
So
in
that
part
it
would
be
a
huge
endeavor
and
I
don't
know
what
the
what
the
return
for
that
is
immediately.
I
mean,
of
course,
if
I
had
a
choice
yeah,
I
would
like
it
to
be
better.