►
From YouTube: Ceph Crimson/SeaStor OSD 2020-07-22
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
Let's
start
that's
weak
I
mean
I
was
working
on
some
other
streams.
It's
just
like
the
anemic
Butte
and
also
reveals
them
there
being
a
tree
named
yeah,
and
this
week
I
will
rip
up
your
review
and
pretend
to
the
crash
when
in
doubt
at
every
place
at
Hearst.
That's
it
to
me.
I.
C
D
It
occurred
to
me
that
I
can
put
off
free
space
handling
almost
completely
and
do
it
all
in
memory,
so
the
lb8
remapping
itself,
authoritative,
Li,
represents
all
uses
space
right
if
it's
not
mapped
by
the
LBA
tree.
It's
not
use
so
during
startup
is
just
gonna
scan
the
LBA
tree
and
count
up
all
of
the
blocks
and
use
in
each
segment
and
then
just
maintain
that
Napa
memory.
It's
like
a
few
thousand
entries.
It's
basically
free
like
a
megabyte
of
space.
D
It's
a
little
expensive
for
the
initial
scan,
but
we
can
improve
it
later.
If
we
need
to,
and
the
main
trade
off
during
operation
is
that
when
cleaning
segments
we'll
have
to
do
a
bunch
of
reads
to
find
out
whether
blocks
are
still
in
use
or
not,
but
the
truth
is
for
qlc
flash
in
particular
I
think
we
always
want
to
trade
reads
for
writes
until
we're
done,
but
we
have
proof
otherwise,
so
I
think
we'll
go.
D
Implement
this
and
we'll
do
some
performance
testing
and
find
out
how
it
does
it
has
the
benefit
of
being
super
easy,
so
I'll
be
able
to
get
this
and
save
them
cleaning
gun
at
the
same
time,
I
think
it's
so
correct.
We're
still
we're
still
writing
down
transactions
that
represent
whether
things
are
you
Bob.
It's
just
that
on
startup,
we'll
have
a
structure
we'll
have
to
rebuild.
D
D
If
it
is
a
problem,
then
we'll
do
the
thing
we'd
have
to
do
anyway,
so
it's
all
I
think
we're
losing
anything.
I.
D
C
D
What
I'm
working
on
now
in
a
week
or
two
or
I'm
off
next
week,
so
this
will
probably
take
several
weeks,
but
after
that
we
should
have
enough
that
I'll
be
able
to
wire
up
something
stupid
and
do
performance
testing
with
up
I/o
or
something
it'll
be
below
the
level
of
the
rest
of
the
outlet
store
functionality.
So
it
doesn't
require
anything
else.
Just
transaction
manager.
A
C
A
But
that
is
somehow
it's
fair
to
find
as
a
right
and
remover,
and
it's
just
this
compiler
complains
that
it
can
that
remover
is
a
incomplete
type,
still
I'm
still
struggling
with
it.
I
will
try
to
come
up
with
that
with
when
unit
at
which
just
exerciser
remover
tried
to
find
out
the
minimal
minimal
the
producer,
because
yeah
hello,
other
example
works
for
me,
but
when
it
comes
to
a
remover,
is
that
it
fails?
I
will
find
out.
Why
trying
to
try
to
finish
up?
Okay,
we'll.
C
C
I'm
currently,
the
next
step
is,
is
the
internal.
Our
first
fight
will
implement
a
unit
test
for
for
the
internal
nodes
plate
and
then
you're,
using
that
those
tests
to
implement
the
plate
to
complete
this
plate
logic
actually
for
the
internal
node,
then
I
will
start
working
to
make
it
work
on
the
see,
stop
block
layer.
A
D
Let's
back
up
a
level,
so
I
don't
think
it's
ever
a
good
idea
for
us
to
map
an
extent
with
unused
space
first
thing.
So
if
let's
say
at
some
point,
an
object
has
a
fork:
ax
down
mapped
and
we
overwrite
one
K
of
that.
I
claim
that
we
should
rewrite
that
entire
extent.
We
should
not
keep
three
K
of
it
and
write
a
new
extent
with
only
one
can
up,
though
I
think
the
same
is
true
of
larger
extents.
D
So
let's
say
we
already
have
a
16
K
extant
written,
and
that
might
happen
if
user
action
or
of
RVD
actually
sent
down
a
16
K
right
for
whatever
ism
right.
If
we
get
a
4k
right
in
the
middle
of
that
I
think
what
we
should
do
is
not
punch
a
hole
in
the
middle
of
the
16k
extent
and
remember
two
old
references
to
the
same
extent,
plus
a
new
one
in
the
middle
I
think
we
should
split
it
into
an
eight
and
two
fours
or
a
16
with
an
actual
mutation
in
the
middle.
D
D
So
if
the
user
submits
a
200
bite
right
in
the
middle
of
an
object,
then
the
layer
above
the
extent
map
whose
only
purpose
in
life
should
be
remembering
the
mapping
from
the
extent
offset
or
from
the
object
offset
to
the
logical
address
the
layer
above
that
should
say:
okay,
this
is
a
200
byte
right,
so
I'm
actually
gonna
grab
the
4k
x.
The
4k
aligned
extent
that
contains
it
or
possibly,
two
of
them
right.
D
If
it
happens
to
cross
a
boundary,
it
should
ask
for
all
extents
that
cross
that
padded
out
value,
then
it
should
return
the
set
of
extent
that
result
from
the
right,
whatever
that
happens
to
be.
If
we
do
it
that
way,
there's
never
ever
ever
a
reason
for
the
extent
map
do
not
map
an
extent
that
starts
the
beginning
of
an
object
or
of
an
extent
at
least
I
can't
think
of
a
reason
why
we
would
need
one.
D
Don't
think
there's
any
reason
to
do
less
than
that,
like
we're.
Never
ever
ever
going
to
do
allocations
that
are
unaligned
like
it
makes
no
sense
for
K
alignment
exists
everywhere
in
the
block
stack
like
if
we
get
a
200
byte
right,
it's
not
well,
it's
nothing
in
the
stack
assumes
that
that's
a
line
there's
no
way.
D
B
B
D
B
D
D
B
D
B
D
A
field
called
size.
The
size
of
the
object
is
the
only
educator
for
everything
else.
Within
the
object
either
there
will
be
an
extent
mapped
or
there
won't
be.
If
there
isn't,
then
it's
a
whole
and
at
zero.
If
there
is
then
whatever
the
bytes
there
that's
the
answer.
There
are
more
sophisticated
strategies,
but
I
don't
want
to
deal
with
them
now
and
they
require
a
hell
of
a
lot
more
design
than
we've
done
so
far.
For.
D
D
A
D
A
D
Yes,
the
user
would
have
so
the
in
that
it
has
to
work
that
way
anyway,
because
you
can
only
read
whole
blocks.
So
if
you
get
a
right
at
offset
4100,
you
have
to
request
all
of
the
extents
that
overlap
that
block
do
whatever
you're
gonna
do
to
them
and
then
write
back
the
results
back
to
the
extent
map.
It
might
be
that
you
mutate
the
blocks
in
place,
in
which
case
you
don't
have
to
do
anything
to
to
the
extent
map.
D
It's
just
journal
deltas
or
it
might
be
that
you
have
made
choices
that
let's
say
now.
The
extent
has
been
is
as
old,
and
you
want
to
rewrite
it.
So
you'll
read
a
new
extent
copy
the
data
over
to
it
and
then
replace
the
logical
address
in
the
accept
map,
but
that
logic
needs
to
happen
above
the
extent
map
or
several
reasons.
First
extend
map
that
H
is
an
interface
from
this
I
infer
that
the
goal
is
to
later
have
other
implementations.
A
A
D
A
D
Exactly
what
we're
doing
here
now
later
on,
if
we
want
to
do
something
clever
like
tail
packing,
which
is
the
the
thing
where
you
take
the
ends
of
objects
which,
for
instance,
for
very
small
objects,
let's
say
you
have
a
200
plate
objects.
You
don't
really
want
to
use
a
whole
4k
extent
for
that
right,
we're
going
to
for
now,
but
you
don't
really
want
to
so
what
you
could
do
is
the
transaction
manager
could
remember,
and
it's
like
a
block.
D
It
has
on
disk
that
it's
packing
little
bits
into
and
every
and
we
you
would
then
update
extent
manager.
You
can
either
update
extent
manager
to
be
able
to
remember
more
about
this
to
say:
oh,
this
isn't
a
real
extent.
This
is
a
blob
that
has
separate
accounting
rules
or
it
could.
If
it's
just
the
tail,
it
could
be
an
extra
member
of
oh,
no,
because
there'd
only
be
one
of
them
right,
just
the
end
of
the
object.
That
would
be
enough
to
optimize
for
small
I
guess
that
case.
C
D
D
That
it's,
for
instance,
if
we're
targeting
our
BD,
there
are
no
200
bite
objects
in
our
VD
ever
they're
all
4
4
megabytes.
Moreover,
rights
already
come
down
in
page
size
increments.
Anyway,
we
don't
get
fours.
We
don't
get
some
4k
size
rights,
not
a
thing
not
really,
because
it
comes
typically
from
a
file
systems.
Page
cache
right
in
real
life,
our
be.
D
Yes,
it:
what
is
what
its
gonna
be?
Is
it's
going
to
be
that
the
extent
map
never
Maps
things
smaller
than
the
transaction
managers
minimum
lot
size?
So
it's
not
even
a
cannot
even
a
config
setting
it's
a
it's
an
API
call.
You
just
ask
the
transaction
manager
what
the
small
sizes
I
haven't
bothered
to
set
it
up,
but
it's
okay
for
now,
I
mean.
A
D
D
D
D
A
D
D
A
D
D
D
C
D
D
What
we're
doing
is
worked
works,
we're
tracking
the
total
amount
of
free
space
in
buckets.
So
if
there
are
a
thousand
segments
on
the
whole
disk,
then
we
track
the
amount
of
free
space
in
each
segment
once
it
gets
low
enough.
We
go
through
the
segment
and
remove
everything,
that's
life.
After
that
the
segment
is
completely
free.
We
don't
remember
which
4k
pages
are
alive.
We
just
remember
whether
an
entire
segment
is
life.
Oh
right.
A
D
A
D
B
D
B
D
It's
a
block
layer
right
block
layers,
don't
tend
to
get
itty-bitty
random
rights.
Most
discs
can't
even
handle
it.
So
for
that
reason
we
don't
want
to
optimize
for
little
rights.
It
doesn't
make
sense.
So
if
we
do
get
a
little
right,
we're
just
going
to
do
something
stupid,
we're
going
to
allocate
a
big
space
around
a
little
right
and
treat
it
as
though,
or
a
big
right.
B
B
D
D
You
won't
typically
put
the
zeros
on
disk,
but
if
anyone
does
do
a
read
to
those
extents,
you
have
to
return
zero.
So
in
our
case,
if
you
write
to
a
very
far
out
extent
on
in
the
in
the
object
like
four
megabyte
and
the
object
is
empty,
then
we'll
allocate
a
little
fork.
A
chunk
around
that
write
with
zeros,
except
for
the
part
you
wrote
and
the
rest
of
the
object
will
be
implicitly
zero.
D
But
the
important
part
is
that,
as
far
as
the
extent
nap
is
concerned,
it
doesn't
care
the
extent
that
it
maps
that
whatever
offset
is
the
data
and
the
user
above
will
have
ensured
that
whatever
data
actually
got
written
gets
written
into
the
extent
and
the
parts
that
need
to
be
zero
will
actually
be
zero.
So
the
read
results
will
be
correct
in
the
future.
B
D
Let's
say
you
do
a
right
at
4,
K
plus
200
bytes
for
240
100
bytes
from
keifa's
example.
Well,
is
that
4
k
plus
100
is
that
0
x4
yeah
anyway,
though?
The
what
will
happen
is
the
user
layer
will
allocate
1
for
K
extent,
starting
at
4
K.
So
the
extent
map
will
contain
a
single
extent,
beginning
at
4k
of
length
4k,
yes,
the
first
100
bytes
of
that
extent
will
literally
be
0
because
they
have
to
be
yes.
D
B
B
D
B
D
That's
all
that's
going
on
here.
It's
really
no
different
from
the
way
blues.
Blue
store
works
more
like
this
is
a
normal
way
of
handling
things.
If
you
don't
expect
to
handle
a
lot
of
small
files
in
the
future,
if
we
do
need
to
handle
small
files,
we
will
have
to
do
something
smarter,
but
this
will
work
for
now.
B
D
D
And
I'm,
okay
with
other
designs,
I
just
want
like
when
you're
writing
out
your
interface
people
reading
or
reviewing
your
code
and
later
on
people
reading
your
code
because
they
need
to
either
use
it
or
expand
upon
it
or
whatever
or
just
understand
it.
They're
not
going
to
be
able
to
guess
necessarily
how
you
meant
it
to
be
used.
So
it's
really
really
helpful
to
have
at
the
top
of
the
interface,
for
instance,
just
an
example
of
how
you
expect
the
user
to
work.
B
A
D
B
B
D
D
D
D
B
B
A
A
D
C
A
D
A
C
D
What
happens
here
is
the
first
right
causes
the
object
size
to
be
40
through
to
be
4k
plus
300
right.
That's
not
that's
like
we're.
That's
not
optional!
We're
required
to
do
that
because,
because
of
the
way
Rados
works,
several
components
rely
on
us.
So
after
the
first
right,
the
size
is
4k
plus
300
after
the
second
right,
the
size
is
12
k,
plus
300.
D
D
B
D
B
D
B
D
B
D
A
literal
extent
that
has
4k
of
zeros
and
100
bytes
of
something
that
offset
100
right,
but
the
rest
of
it
zeros,
and
it
really
is
data.
It's
like
there's
no
later
on,
there's
no
difference
between
those
zeros
and
100
bytes,
the
user
wrote
in
fact
those
hundred
bytes
could
be
zeros.
We
may
not
have
bothered
to
check
ok,
similarly,
the
13k
one
that
actually
falls
at
pass
to
the
end
of
the
object.
D
B
D
There's
nothing
preventing
the
user
from
actually
writing
zeroes
M.
If
the
user
writes
an
entire
page
of
zeros
at
offset
zero,
we
actually
could
you
just
not
do
the
mapping
right.
We
already
have
rules
that
say
we
were
gonna
return
zero
anyway,
so
it's
a
no
op.
All
we
have
to
do
is
update
any
end
time
or
whatever
stuff
right
there
genuinely
is
no
difference
between
implicit
zeros
because
there's
a
hole
and
zeros.
We
remember
because
it
happens
to
fall
into
an
extent
we
bothered
to
map
from
the
users
point
of
view.
B
C
A
D
Mean
we
will
optimize
out
internal
holes
forever,
we're
talking
about
crumbs
that
are
of
the
size
of
few
kilobytes
right,
but
if
we,
if
real
RBD
objects,
are
four
megabytes
in
size,
that's
a
thousand
of
these
guys.
So
if
we
get
a
few
for
K
right
spread
throughout
the
object,
we're
not
really
gonna
fill
that
hole
for
megabytes.
We're
just
gonna.
Have
a
few
pages
mapped.
A
D
Plus
you,
the
overall
metadata
size
gets
bigger,
so
you
need
to
spend
more
CPU
cycles.
Finding
the
right
extent.
There
are
more
branches,
you
have
to
do
more,
offset
calculations
and
corrections,
it's
just
more
complicated
and
since
we're
never
going
to
get
unaligned
rights
in
the
first
place,
it's
not
worth
optimizing
for.
D
B
D
D
D
A
D
B
B
B
B
B
B
C
B
B
D
B
D
B
D
B
D
Row
in
TN,
minus
1,
that's
M,
so
I
don't
know
exactly
what
design
you're
using,
but
the
standard
way
this
works
is
for
the
internal
node.
You
have
n
pointers
to
child
notes
and
between
each
two
of
them
you
have
a
pivot,
which
is
why
they're
add
minus
1
of
them,
so
key
space
at
minus
1
in
the
internal
node.
That
should
be
M.
C
B
D
B
D
B
So
so
that
it's
layout
of
all
the
inner
node
and
the
leaf
nodes,
so
the
the
stream,
the
case
3
and
the
y
low
string
also
started
both
starred
in
the
in
the
right
side,
and
the
left
side
is
fixed
outside
v.
Less
outside
recorder,
where
the
this
history
and
registry
is
so
that
is
easy
to
calculate
the
position
for
each
atom.