►
From YouTube: Ceph Performance Meeting 2021-07-29
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
So
prs
this
week,
the
only
new
one
that
I
saw
was
from
me.
This
is
not
really
performance
yet,
but
we'll
get
there.
I
think
I'm
going
through
and
refactoring
memstor
a
little
bit.
A
This
includes
the
vector
object
from
pet
store
from
a
couple
of
years
ago,
which
no
longer
appears
to
be
faster
than
buffer
list,
which
is
great,
because
buffer
list
was
awful
before
it
was
notably
slower,
and
I
think
a
lot
of
the
work
that
radek
has
done
over
the
last
couple
of
years
has
has
basically
made
it
as
fast,
if
not
maybe
slightly
faster
than
the
thing
I
did
so
that's
great.
A
That
is
just
really
pulling
stuff
apart
a
little
bit
to
make
it
so
that's
easier
to
change
things
in
it,
I'm
probably
going
to
try
to
figure
out
why
memstor
appears
to
actually
be
significantly
less
efficient
in
the
right
path
than
blue
store,
which
is
kind
of
interesting,
but
that
also
seems
to
be
somewhat
true
for
well.
Actually,
no,
I
think
that
back.
I
thought
it
was
true
for
science
store
as
well,
but
I'm
I
don't
think
so.
A
It
looks
like
we're
actually
pretty
good
on
the
right
path
there
so
anyway,
that's
that
what
else
close
stuff
braddock
made
a
really
clever
change
that
allows
alien
store
to
use
any
classic
object
store,
rather
than
just
blue
store.
So
now
we
can
run
mem
store
an
alien
store,
or,
I
guess
maybe
file
store
so
that
merged.
I
keep
who
merged
that
this
little
pr
from
me
that
sets
the
osd
client
message,
cap2256
that
looked
reasonable
in
testing,
so
we
just
changed
it.
A
I
think
that
fixes
something
that
people
are
seeing
related
to
heartbeat
timeouts
in
production,
this
avx
512
erasure
coding
implementation,
has
been
closed
by
the
author.
They
no
longer
have
the
ability
to
test
it
apparently
or
update
the
pr.
So
I
don't
know
how
much
we
actually
care
about
it,
but
that
got
closed,
updated.
A
There's
this
pg
log
acceptable
rollback
info
troops
to
vr.
If
we
reviewed
it,
he
wants
them
to
take
a
look.
I
knew
I
heard
you
as
a
reviewer
on
that
as
well.
B
Yeah
yeah.
I
saw
that
one
comment.
Those
are
a
little
tricky,
so
I
want
to
spend
a
little
more
time
to
understand.
You
know
it's
gonna
be
detrimental
in
some
way.
In
general,
it
looks
fine
harmless,
but
just
want
to
spend
some
more
time
there.
A
A
All
right,
let's
see,
rgw
tracing,
matt
and
plus
I
don't
know-
has
been
reviewing.
That
looks
like
it's
actively
being
discussed,
though.
So
that's
good.
A
This
carriage
handling,
optimization
in
bufferless,
c-string,
bio-radic,
kiefer
reviewed
it
ilia
had
a
couple
nits,
but
otherwise,
maybe
that
looks
good
finisher
kind
of
basically
giving
up
cpu
automatically
optimization
there.
Kifu
and
casey
are
reviewing
it
under
kind
of
active
discussion.
What
that
should
be
exactly
how
how
much
it
should
give
up
how
much
concurrency
should
be
allowed.
So
there's
that.
A
A
This
time
to
live
cash,
implementation
for
the
manager,
the
thing
continues
to
be
updated.
I
don't
know
what
all
the
updates
actually
have
been,
but
it's
been
actively
worked
on
igor's,
pg
removal.
Pr
kifu
is
doing
more
review
on
that.
I
think
it
may
be
past
testing
at
one
point,
but
you
must
have
seen
a
couple
things
that
he
wanted
to
talk
about.
A
I
think
that's
all
we've
got
for
this
week,
still
a
bunch
of
other
random
stuff
in
the
new
movement
pile.
I
don't
think
anything
real
relevant
to
talking
about
today-
eber's,
not
here
so
and
nor
is
adam.
So
I
guess
none
of
the
oh
no
trim
stuff
about,
but
all
right.
So,
let's
move
on
unless
there's
any
pr's.
I
missed
guys.
A
All
right
sage,
did
you
want
to
introduce
this
smr
status
stuff.
D
Yeah
yeah-
and
this
is
a
email
conversation
that
sort
of
got
kicked
off
a
couple
weeks
ago,
but
we
didn't
really
follow
up
so
mostly
just
wanted
to
talk
to
lieb
and
find
out
what
the
current
status
of
the
smr
implementation
in
blue
store
is
and
what's
remaining
and
what
the
path
forward
is.
So
I
know
a
whole
bunch
of
work
merged
last
year
that
I
sort
of
I've
missed
those
out.
I
didn't
I
haven't
reviewed,
I'm
not
really
sure
exactly
what
it
does
and
doesn't
do
yet.
E
Okay,
can
you
hear
me.
D
E
Yeah,
okay,
so
yeah,
I
I've
been
working
on
it
by
myself.
I
had
one
student
helping
me
a
little
bit,
but
that
was
a
master's
student.
So
it's
gone
so
I've
been
working
on
it
on
and
off
and
igger
was
reviewing
the
patch
test.
So
a
bunch
of
stuff
that
I
did
originally,
I
had
to
redo
it
based
on
igor's
feedback,
so
the
status
now
is
so
the
the
one
annoying
thing
is,
I
work
on
it
for
a
while,
and
then
I
come
back.
E
I
rebuild
stuff
is
not
working
because
some
change
broke
stuff,
so
I
go
and
try
to
find
what
caused
that
and
fix
it
again
and
then
continue
and
right
now,
I'm
in
one
of
those
stages
again
and
the
nice
thing
is
the
change
that
broke
it.
I
figured
out
the
commit
and
there's
just
I
comment
out
one
line
and
it
it
works
again
anyway.
The
what's
remaining
is
so
last
we
were
discussing
with
eager
how
to
how
to
so.
We
were
storing
for
every
object.
E
We
were
storing
metadata
in
rugsdb.
The
way
we
store
it
is
there's
a
separate
namespace
and
in
that
namespace
we
have.
E
Appended
to
each
other
and
the
value
is
the
offset
of
the
object
within
the
zone
and
whenever
we,
let's
say
add
a
new
object
to
a
zone.
Whenever
we
write
a
new
object
to
zone,
we
create
one
such
entry.
Whenever
we
delete
an
object,
we
delete
this
key
value
record
and
whenever
we
update
the
object,
let's
say
either
by
writing
to
the
same
zone
at
the
later
offset.
E
We
update
this
and
this
way
when
it's
time
to
clean,
we
query
that
namespace
with
just
the
zone
name,
and
that
gives
us
the
oids
of
all
the
objects
within
that
zone
and
the
values
are
the
offsets.
E
So
we
were,
I
originally
implemented
it
like
this,
and
then
we
were
discussing
with
eager
that
since
so
to
read
an
object
now
where
we
have
come
to
this
cleaning
stage,
where
we
need
to
read
the
objects
from
the
zones
and
copy
them
somewhere
else
and
the
problem
there
is.
When
you
read
the
object,
when
you
read
the
oid,
you
cannot
just
get.
You
cannot
read
the
object
just
from
the
oid.
You
also
need
the
collection
id.
E
So
so
we
and
then
we
thought
about
storing
the
collection
id
as
well,
but
then
you
cannot
store
collection
id
because
the
objects
may
split.
I
mean
the
collections
may
split
and
merge
so
cid
become
I
mean
there
our
knowledge,
our
understanding
of
cids
is
a
bit
weak.
We
tried
to
understand
the
code
and
and
then
we
weren't
sure
how
to
do
it.
E
In
the
last
comment,
igor
proposed
an
idea
about
how
to
do
this,
but
I
haven't
read
through
and
thought
thought
it
through
yeah.
What.
D
I
think
it's
the
the
gh
object
id
includes
the
pool.
You
basically
need
the
pool
identifier
and
you
need
to
know
the
like.
The
erasure
coding,
shard,
I
think,
are
the
two
things,
and
that
should
be
enough
that
and
then
the
question
is
really
just
like
a
subset
of
the
the
pool
id
on
that.
So.
D
E
So
that's
where
we
are
in
terms
of
in
terms
of,
and
then
what's
another
thing
that
so
the
next
step
after
that
is
to
implement,
do
move
which,
like
similar
to
do
read
the
do
move
that
atomically
moves
an
object
from
its
current
location
to
somewhere
else,
so
that
to
move
needs
to
be
implemented
and
then,
after
that,
implementing
the
we
already
have
the
logic
in
place
to
like
consistently
clean
a
zone
after
that
that
needs
that
waits
for
two
move
to
be
implemented
once
the
move
is
implemented.
E
I
think
it's
my
like
ultimate
commit
where
I
specify
how
to
do
that
yeah.
So,
the
after
that
we
have
like,
we
have
a
complete.
You
know,
assuming
all
the
flags
are
fixed.
We
have
a
basic
working
system,
yeah
yeah
working
system.
So
right
now
we
can
write
data
to
smart
disks.
E
We
can
shut
down
the
system,
we
can
start
and
read
the
stuff
that
we
have
written,
but
we
need
to
come
to
the
now
yeah
the
what
metadata
we
need
to
persist
and
then
implement
to
move.
E
Those
are
two
key
things
left
to
get
the
basic
things
working
yeah
and
then
the
the
fun
part
for
us
starts,
which
is
like
there
are
many
design
decisions
and
I'll
be
exploring
with
the
new
student
that
comes
in
how
to
like.
There
are
many
design
decisions
about
the
like
space
allocation
and
object,
placement,
and
so
on.
E
What
the
policies,
so,
once
we
have
this
basic
thing
working,
then
we
can
start
having
fun
with
it,
but
and
yeah
like
in
your,
if
you
like,
assuming
you're,
actually
targeting
with
this
really
large
object,
given
that
people
are
using,
who
use
smr
will
store
on
them,
really
large
objects,
people
may
get
things
work,
it
may
be
used
because
the
zone
size
is
256
megabytes.
So
if
you
store
like
gigabyte
size
objects
on
it,
then
you
don't
even
need
cleaning,
yeah,
yeah.
E
Okay,
yeah
so
yeah
I
forgot
about.
I
forget
about
that.
You
still,
even
if
the
user
writes
gigabyte
objects,
you
still
need
to
chunk
it
yeah
store,
smaller
radius
objects
yeah.
So
that's
where
the
instead
of
this
status
is
okay.
I
think
it
would
be.
I
don't
know,
what's
the
like,
I
think
it'd
be
nice.
If
so
yeah
I
was
busy
with
a
bunch
of
other
real
lifestyle
stuff,
so
I'll
I'll
resume
working
on
it
next
week
and
I
will
have
students
working
on
it
as
well.
E
I
think
if
someone
I
mean
igor
is
responsive,
but
sometimes
it
takes
a
couple
of
pokings
to
get
a
response
from
him
yeah
and
also
because,
since
I'm
working
I've
been
working
on
it
sporadically
like
I
would
do
some
commit
and
then
a
couple
of
weeks
or
three
weeks
would
pass
and
then
I
would
think
eager
to
give
me
feedback,
and
he
also,
since
he
does
a
thorough
job
he
needs
to.
You
know,
bring
everything
into
cash.
To
remember
where
things
are
so
it
takes
time
as
well
from
him.
E
So
I
hope
like,
if
I
mean
eager,
is
nice,
but
maybe
someone
else
if
someone
else
could
also
give
review
the
review
the
appears
that
would
help.
D
I
have
a
couple
quick
questions
about
the
status
that
so
all
the
all
of
the
bluefs
stuff
is
already
done
right.
Is
that
all
all
that's
entry.
E
No,
so
the
bluffa
stuff-
actually
none
of
it
is
done
because
what
we
did
here
is
we,
just
since
smr
drives,
have
out
of
the
cmr
version
of
range
random,
random,
write
region
which
is
like
500
something
zones
which
is
pretty
huge,
so
the
current
code
just
writes
the
rugsdb
into
that
region.
E
I
see
okay,
but
that
smart
stuff
I
mean
the
blue
for
stuff
that
can
also
be
integrated
but
yeah
it.
I
I
just
thought
that's
a
soul
thing,
and
given
that
we
have
this
zone,
I
just
try
to
get
the
smr
party,
because
this
part
is
the
more
complicated
part
working
immediately.
D
Yeah,
okay-
and
I
imagine
that
we
can-
we
could
probably
avoid
doing
that.
The
complicated
part
of
the
rocks
db
with
the
the
log
file
append
stuff
working,
because
that
part,
the
log
files
that
we're
appending
to
with
small
writes,
could
always
go
in
the.
E
I
mean
well
right
now
the
yeah
I
can
specify
roxdb.
As
a
I
mean,
I
can
specify
a
single,
a
smart
drive
as
a
as
a
as
the
whole
drive
and
and
yeah
I
needed
to
actually
check
it.
I
don't
remember
exactly,
but
basically
there
is
a
few
gigabytes
of
play
space
where
you
can
write,
you
can
do
random
rights
and
all
the
rights
to
be.
E
I
actually
pre-allocate
yeah
once
that
I
I
start
allocating.
I
just
preserve
that
whole
region
for
rex
tv
and
then
start
allocating
actual
data
from
the
smr
smr
region.
D
Yeah,
okay,
okay,
that
makes
sense.
I
have
a
couple
questions
about
the
the
reverse
index
they
were
talking
about
is
so,
if
I
remember
you
said
it's,
it's
basically
a
tuple
of
the
zone,
identifier
and
the
object
id
and
the
index
that,
like
the
object,
the
offset
with
the
knee
and.
E
Yeah,
the
key
is
the
key
is
zone
id
plus
concatenation
of
zone
id
and
the
oid,
and
the
value
is
the
offset
within
the
zone.
E
So
the
the
assumption
is,
we
write
the
whole
object
into
zones.
D
E
E
Okay,
so
I
think
our
assumption
was
yeah.
Our
assumption
was
like
the
rgw
workload
where
you
have
complete
zones
and
you
do
not
have
like
updates
zones.
So
you,
you
write
complete
zones
and
you
delete
sorry,
you
write
complete
objects,
you
delete
complete
objects,
yeah,
and
in
that
case
you
you
can
only
you
can
only
either
overwrite
the
object
or
you
can
delete
the
object
or
you
can
write
a
new
object,
see:
okay,.
D
D
Key
structure,
because
I
guess
the
downside
to
this
key
structure
is
that
when
you,
when
you
are
doing
the
cleaning,
the
all
these
keys
in
the
zone
are
going
to
be
like
randomly
ordered,
based
on
where
they're
actually
located
in
the
zone.
E
Yes,
like
the
keys
you
yeah,
so
when
cleaning
you'll
just
query
by
the
zone
number
in
the
namespace
and
that
will
give
you
the
list
of
objects.
D
The
object
will
be
in
random
order
effectively.
So
so,
like
I'm
just
like
thinking
out
loud
here,
an
alternate
one
alternative
approach.
I
don't
know
if
you'd
look
at.
If
you
have
the
pad
open,
you
might
want
to
open
the
pad
because
I'm
taking
a
chat
because
an
alternate
key
structure
might
be
zone
and
then
zone
offset
map
that
to
object
id.
E
Yeah
I
opened
the
I
opened
the
ad.
E
D
E
See
so
you're
saying,
zone
and
zone
offset
and
option.
E
E
D
D
E
E
Yeah
yeah,
I
don't
know
what
I
originally
had
there,
but
pro
because
this
is
like
this
current
scheme.
I
originally
had
something
else.
I
don't
remember.
I
need
to
check
this.
One
igor
suggested
this
one
and
okay.
E
E
D
I
guess
so
the
problem
with
the
second
one
is
that
you,
you
would
need
a
new
one
of
these
every
time
you
have
a
different
extent
in
the
zone.
That
has
data
for
that
object,
and
so
there
might
be
multiple,
and
so
you
just
have
more
metadata
more
keys
to
deal
with
that's
a
cost,
but
we
don't
really
care
about
all
the
different
offsets.
D
F
E
So
are
you
so
again,
our
assumption
was
like
write
one's
object,
so
you
just
are
you?
Are
you
also
changing
that.
D
Well,
I
think
I
think
we
need
to
make.
I
think
we
need
to
make
blue
store
work.
It
needs
to
be
fully
functional,
regardless
of
what
the
I
o
pattern
is.
It
just
doesn't
have
to
be
efficient
in
that
case
right,
so
we
can
say
you
shouldn't
use
smart
drives
for
random
block.
I
o
right,
but
if
you
have
an
existing
object
and
you
overwrite
the
middle
of
it,
we
don't
want
the
oc
to
like
return,
an
error.
It
needs
to
still
do
it
even
if
it's
inefficient.
E
I
mean
okay,
if
you,
if
you
want
to
support
like
a
general
general
case,
then
yeah
this,
we
may
need
to
rethink,
we
actually
haven't.
I
I
personally
haven't
thought
about
the
general
case
where
you
can
have
random
override
of
an
I
mean,
not
random,
all
right,
like
override
partial,
override
or
extending,
depending
an
object
and
so
on.
So
I
think
you're
trying
to
address
all
those
cases
right.
D
And
so
it
shouldn't
really
be
more
work
as
long
as
yeah,
I
don't
think
it'll.
In
fact,
it
would
probably
be
more
code
to
write
to
make
it
not
work.
E
No,
it's
only
about
like
yeah.
I
think
the
only
thing
is
the
assumptions
that
we
made
about.
So
the
assumptions
we
made
I
made
was
a
single
object.
First,
we
like
the
simplest
possible
case,
which
is
you
can
write,
complete
objects
within
a
zone.
You
can
overwrite
a
complete
object,
which
means
I'm
just
writing
the
same
object
with
new
content
somewhere
else
or
you
can
delete
an
object
and
some
further
assumptions
are
an
object.
E
May
not
will
only
leave
within
a
single
zone
like
it
may
not
be
partially
like
if
it's
let's
say
you're
at
the
end
of
the
it
does
not
like
live
partially
in
this
zone
and
yeah
and
then
okay.
So
so,
if
we
are
considering
a
general
case,
then
probably
which
is
which
would
be
nice,
I'm
just
again,
this
was
originally
just
to
get
something
working
so
that
I
could
get
the
performance
numbers.
E
Then
we
can
think
about
how
to
do
better
indexing
that
support
all
those
cases.
So,
okay,.
D
Okay,
well,
maybe
maybe
the
thing
to
do
is
to
I
can
spend
some
time
and
just
look
at
the
current
code
and
see
what
it
how
it's
implemented,
because
mike
I
think
I
mean
I
think,
if
you're
designing
something
from
scratch.
Those
simplifications
would
make
a
lot
of
sense.
D
It
would
make
everything
much
simpler,
but
we
already
have
all
the
infrastructure
for
having
tons
of
different
extents
within
an
object,
all
these
different
blogs
and
all
the
checksums
associated
with
them
all
that
and
for
allocating
and
deallocating
doing
partial,
overrides
and
stuff,
like
all
that
stuff
already
exists,
and
so
I
think
making
something
that
only
supported
the
simple
cases.
You're
talking
about
would
mean
right.
E
D
E
You
sure
it's,
I
think,
the
only
yeah
I
mean
I
I
didn't
have
like.
I
didn't
have
a
really
good
understanding
of
only
like
you
know.
Apparently
you
have
like
extends
and
like
a
couple
of
layers
of
things.
E
Why
I
kind
of
targeted
so
yeah?
If
you
spend
that
time
on,
you
know
if
you,
if
you
think
about
how
and
then
how
you
can
design
it
better
and
also
explain
it
to
me
yeah
that
would
be
okay.
D
Yes,
so
there's
there's
an
allocator:
is
there
there's
an
allocator
implementation?
That's
in
there.
E
Yeah,
the
allocator
yeah
that
it's
it's
all
all
of
them
are
rudimentary
like
allocator
and
the
freelance
manager,
it's
the
allocator,
just
sequentially
allocates
a
stuff
starting
from
some
beginning
zone
and
and
goes
on
like
this,
like
we
do
not
handle
the
cases
of.
Let's
say
when
the
disk
is
full
because
that
relies
on
implementing
garbage
collection
yeah.
So
it's
yeah,
there's
an
allocator
there,
there's
an
allocator
and
a
free
list
manager
so
for
each
zone.
E
We're
tracking,
also
we're
tracking
the
number
of
dead
bytes
within
a
zone
and
the
offset
the
current
right
pointer,
we're
tracking
two
things,
and
every
time
we
allocate
something
the
allocator
allocates
something
those
two
things
are
updated.
I
mean
the
allocator
only
updates
it
when
lk's
new
space
is
mostly
right
pointer,
but
then,
whenever
we
delete
object,
we
increment
the
number
of
deadbytes
within
the
zone.
E
Yeah
got
it
and,
and
then
the
cleaner
selects
does
a
select,
does
a
sort
on
the
current
zones
based
on
the
number
of
dead,
bytes
and
selects
the
zone
with
the
dead
bites.
Basically
3d
cleaning
at
this
point
yeah.
That's
there.
I
mean
it's
not
a
lot
of
code.
I
think
you
can
just
spend
like
I
don't
know
a
few
hours
to
go
through
it.
Yeah,
okay,.
D
Okay,
cool
sounds
great,
and
then
I
guess
there's
this.
There
was
a
related
discussion
on
the
thread
about
actual
smr
hardware.
E
D
E
Yeah
the
reason
I
wanted,
that
is
at
least
like
if
we
could
have
like
it
on
a
small
cluster,
just
for
making
sure
that
so
right
now
there
are
two
breakages
that
I
still
haven't
debugged.
I
was
just
discussing
one
with
careful.
Basically,
what
happens
is
people
add
code
and
they
do
not
if
they.
If
the
smr
code
was
being
actually
tested
in
the
test
servers,
they
would
see
the
code
breaks
and
they
would
fix
it.
E
But
right
now,
since
it's
not
being
tested,
they
just
they
just
keep
adding
code
and
it
breaks.
And
then
I
have
to
figure
out
what
how
to
fix
it.
I
mean
yeah.
I
think
it's
between
you
and
mathias
had
to
decide
how
to
do
that,
but
I
think
the
sooner
you
have
at
least
a
few
for
the
test
for
the
test
servers
and
until
just
to
avoid
the
code
right.
D
So
mark
are
there
any
of
the
like
smaller
subsets
of
machines
that
have
empty
dry
base
that
we
could
put
smr
discs
in.
A
Not
really
I
mean
inserta,
we
could,
we
could
maybe
take
out
some
of
the
existing
drives
to
add
them
in,
but
I
don't
know
of
any
other
machines
that
have
like
you're
talking
three
and
a
quarter
or
three
and
a
half
inch
driveways.
D
A
D
E
D
So
there
are
some
to
leave.
There's
some.
There
are
some
unit
tests
for
blue
store,
like
there's
that
run
that
do
a
whole
bunch
of
like
obnoxious
tests.
If
we,
if
we
could
make
those
work
with
like
a
simulated
environment,
that
would
be
that'd,
be
pretty
valuable
because
they're
doing
like
all
these,
like
these
torture
tests
with
like
allocation
randomly
allocating
and
de-allocating
stuff
and
overrides
and
whatever
like.
If
we
could
set
up
one
of
the
simulated
smr.
E
Drivers,
the
way
I
test
it
every
time
I
I
make
a
change
is
I
build
the
build,
restart
and
then
start
the
start,
a
small
cluster
and
then
create
a
pool
and
do
right
of
objects
for
100
seconds.
That's
how
I
test
it.
E
So
I,
if
something
like
this
and
whatever
code
people
are
adding,
is
breaking
that.
Okay,
that
test
sequence
that
I
just
described.
So
if,
if
there's
a,
you
have
a
unit
test
that
does
something
like
that,
which
is
a
pretty
basic,
not
not
a
torture
test,
then
those
would
be
visible
to
the
developers
yeah
yeah.
D
E
And
yeah,
and
actually
we
do
not
need
to
have
the
kind
of
failures
that
I'm
seeing
they
can
be
protected
using
just
the
emulated,
smr
drive
that
can
be
created
in
memory
and
when
I'm
running
my
tests,
I'm
actually
patching
stuff
to
use
like
only
the
first
hundred
zones
so
that
I
could
trigger
garbage
collection.
So
you
can,
you
can
just
create
a
emulated,
drive
in
ram
and
then
use
that
but
yeah.
E
We
do
not
need
to
actually
insert
this,
that
that
would
be
good
enough
until
things
start
working.
D
So
it
starts
working
and
then
we
could
go
get
bunch
of
drives
yeah.
Okay,
yeah!
Do
you
know
a
separate
question?
Do
you
know
what
the
current
like
size
bonus
or
whatever
for
smr
versus
conventional
drives,
is
like
how
much
bigger
flash
cheaper?
Are
the
smr
drives
compared
to
the
conventional
ones?
Whether
it's.
E
E
I
think
it's
ten
percent,
like
with
the
with
the
western
digital
drives
like
they
have
ultra
star,
drives,
that
are,
let's
say
yeah.
I
think
we
can
look
it
up,
but
but
what
they're
saying
is
with
they're
going
to
moving
towards
this
higher
mummer
technology
and
there
it's
going
to
be
much
larger
difference
and
then
the
other
thing
is.
E
If
we
get.
If
we
get
that's
what
I'm
actually
planning
to
also
research
once
we
get,
I
know
you
pl,
you
target
the
cns
drives
with
with
your
new
back
end,
but
if
we
get
smr
working
we
can
just
you
know,
plug
zns
ssds,
and
it
will
work
as
well,
and
some
of
those
zms
ssds
are
actually
targeted
for
qlc
of
flash
most
of
it,
actually
the
primarily
qlc,
which
is
high
capacity.
So
there
will
be
there.
E
There
are,
there
are
planned
and
there
are
plans
to
make
asia
like
enterprise
unnecessaries
that
are
also
low,
latency,
very
fast
and
so
on,
but
primarily
it's
for
qlc,
which
I
think
will
still
find
the
use
in
store
like.
Even
though
once
we
have
that
smart
working.
You
just
need
to
like
put
the
nss
keys
and
it
will
work.
D
E
Okay,
so
it
may
be
much
faster
to
support
yeah.
So,
basically,
when
you
say
you
target
early
2020
2022,
it's
not
just.
If
we
get
this
working,
you
will
not
have
support
just
for
smr.
You
also
have
support
for
dns
ssds,
yeah,
yeah
and
yeah.
One
other
thing
that
they've
mentioned
so
right.
Now
we
have
added
this
z.
E
Lib
zbd
and,
like
the
western
digital
folks,
said
that
zns
smr
zone
storage
support
is
within
the
kernel.
We
do
not
need
any
libraries,
we
should
get
rid
of
dvd
and
the
kernel
provides
ioctals
to
issue.
So
we
do
not
need
an
external
library,
that's
another,
to
do
item
basically
to
get
rid
of
a
live
cbd.
E
F
D
Yeah,
okay,
all
right
cool
josh,
any
other
anybody
else.
Any
other
questions.
B
No
questions
I
just
added
the
object
store
tests
that
we
have
that
do
a
whole
bunch
of
simulation.
That
sage
was
talking
about,
so
you
can
take
a
look
at
that
for
some
examples
already
yeah.
This
sounds
good.
B
D
C
If
we
can
get,
that's
gonna
be
able
to
support
dns.
D
In
addition
to
the
smart
drives,
that's
fantastic
yep!
I
think
if
we
could,
if
we
could
get
the
as
the
like
a
wrapper
script
that
the
last
time
I
checked
that
basically
to
get
the
emulation
set
up,
it's
a
kernel
device
like
you.
Do
it's
like
a
kernel
loopback,
and
then
you
set
up
this
other.
I
can't
require
remember,
but
it's
it's,
because
I
have
to
set
up
a
kernel
block
device
to
do
the
the
emulated
smr
stuff.
D
So
if
we
make
like
a
bash
script
that
sets
all
that
up
and
then
runs
store
test
to
like
consume
that
that
simulated
device,
that
would
be
the
way
to
do
it,
filter
whatever
have
to
figure
out
how
to
yeah.
I.
E
Mean
the
I
think
it's
a
single
line
to
create
an
smr
drive
the
email
thread
in
the
oh,
maybe
yeah.
I
think
the
email
thread
in
email
thread
damien
described
how
to
do
it.
So
there
are
three
options,
but
I
think
the
easiest
one
is
just
the
one
that
creates
an
in-memory
smart
drive.
So
yeah
you
may
want
to
use
a
few
100
zones
which
will
take
about.
I
don't
know
as
much
ram
as
like
I
don't
know.
E
One
gig
drive
should
be
enough
with
four
zones
for
the
basic
test,
just
to
make
sure
that
yeah,
the
the
edit
code
is
not
breaking
things.
E
Okay,
so
I
think
you
you
will
you're
going
to
take
a
look
at
the
code
and
then.
E
Yeah
yeah
yeah:
if
you
come
up,
then
we
can
discuss
the
and
discuss
what
to
implement
and
then
I
don't
know,
are
you
going
to
be
reviewing
the
prs?
Will
you
have
time
for
that
or.
D
I'm
guessing
yes
but
I'll
yeah.
Let
me
let
me
start
by
reading
the
code
and
just
see
where
we're
at
and
then.
B
Okay,
it
make
sense
to
do
some
sort
of
code
walkthrough
of
what
we
already
have
and
where
we
are.
E
I
can't
I
can't
do
that.
It's
again,
it's
not
a
large
amount
of,
but
I
can
do
that
in
very
quickly
if
you
guys
want
next
next
week,.
E
F
A
Only
other
thing
I
had,
although
I
think
most
of
the
people
here
are
from
the
core
meeting,
so
it's
just
the
the
stuff
from
there.
I
linked
it
in
the
ether
pad
the
crimson
classic
performance
and
efficiency
comparison
stuff.
So
for
folks
that
weren't
in
the
core
meeting.
This
is
basically
just
looking
at
how
we're
doing
right
now.
A
Braddock
had
expressed
some
concern
that
we
weren't
really
showcasing
crimson's
benefits
as
much
as
we
could
have
been
by
doing
really
large
data
set
sizes,
whereas
he
thought
that
smaller
datasets
would
show
it
off
better,
and
that's
not
exactly
it's
probably
true
in
the
test
that
you
ran
with
rato's
bench
in
in
fio
rbd
tests.
A
I
think
it's
less
so
possibly
due
to
pg,
lock
contention
when
you
have
very
small
data
sets
with
rbd,
but
in
any
event,
I
ran
a
bunch
of
tests
and
if
you
look
at
the
results
there
in
the
linked
spreadsheet,
the
gist
of
it
is
that
for
reads
random
reads:
small
random
reads:
science
stores
is,
is
quite
efficient,
but
for
alien
store
and
also
especially
on
the
right
path.
Blue
store
is
actually
more
efficient.
A
In
some
cases,
or
at
the
very
least
very
close
to
as
efficient
it's,
not
the
the
kind
of
big
takeaway
from
that
one
is
that
memstor,
for
some
reason,
is,
is
quite
a
bit
less
efficient
on
the
right
path.
A
So
it's
probably
worth
looking
into
that
and
figuring
it
out,
but
interesting
data
here,
hopefully
we'll
we'll
kind
of
figure
out
why
alien
storm
blue
store
on
the
read
path,
specifically
alien
store
kind
of
up
as
the
data
set
size
grows,
but
well
in
any
event,
lots
more
to
do.
You
go
talk
more
about
it
next
week.
Maybe
we
can
get
rid
of
here
too,
because
he
has
opinions
on
a
lot
of
this
too.