►
From YouTube: Ceph Crimson/SeaStore 2021-09-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
All
right
I'll
get
started.
Let's
see,
I
pushed
out
a
patch
last
week
for
at
least
one
pin
crash,
it's
the
one
that
has
parented
it,
hopefully
that
one's
fixed.
Now
I'm
about
to
push
a
pr,
either
tonight
or
tomorrow,
for
a
for
the
a
weight,
hard
limits
crash
and
segment
cleaner.
A
A
So
I
added
support
for
projecting
the
amount
of
unused
space
that
will
exist
once
all
permitted
rights
complete,
so
that
should
solve
the
problem
and
allow
us
the
parallelism
that
we're
currently
enjoying
next
up,
I'm
gonna
work
on
the
cache
lru
so
that
we
can
get
some
meaningful,
recaching
and
yeah.
That's.
B
B
B
I
want
to
trigger
to
write
the
big
buffer
to
the
disk,
for
example
the
big
buffer
size,
what
size
it
is
and
if
I
needed
some
timer
to
trigger
the
the
buffer
to
write
if
the
buffer,
the
big
buffer,
is
not
big
enough.
A
So
my
suggestion
is
not
to
use
a
timer
or
a
threshold
so
that
sort
of
natural
way
to
do
this
is,
if
you
imagine
a
situation
where
we
have
a
right
coming
in
every
second,
then
you
always
want
to
write
those
the
instant
they
come
in
right,
because
if
you
try
to
wait
for
a
megabyte
of
them
or
something
to
show
up,
then
the
latency
would
be
enormous.
It
would
take
hours
for
the
bumper
to
fill
up
and
any
timer.
A
You
use
to
offset
that
if
you
make
it
a
1,
millisecond
timer
you've
guaranteed
a
minimum
write
latency
of
1
millisecond
right,
so
we
don't
really
want
to
use
a
size
or
a
time
threshold
instead.
My
suggestion
is
that
any
time
the
anytime
you're
not
currently
writing
write
whatever's
in
the
in
the
buffer.
A
A
So
as
with
file
store
journal
or
a
lot
of
journal
implementations,
really
you
want
to
make
it
so
that
you
write
any
data
that
shows
up
as
soon
as
it
shows
up
unless
there's
already
a
right
happening.
A
If
there's
already
a
right
happening,
you
stick
it
in
the
you
know
the
buffer
to
be
written
when
the
next.
When
that
write
completes
and
then
when
that
ray
completes,
you
go
ahead
and
write
whatever's
in
the
buffer,
so
there's
always
a
right
happening
and
you
only
actually
build
up
things
in
this
buffer.
If
things
come
in,
while
the
previous
write
is
occurring.
B
So
so,
just
like
what
I
do
before
use
the
swipe
right,
the
one
buffer
is
written
and
another
one
is
wait
there
and
if
the
written
written
list
is
finished,
then
swap
to
the
another
buffer.
A
A
The
other
thing
you'll
need
to
take
care
about
is
when
you
hit
a
a
segment
roll.
You
need
to
make
sure
that
you
don't
accidentally.
I
can't
remember
actually
how
that
code
works,
but
make
certain
that
you
don't
batch
up
so
much
that
you
write
past
the
end
of
a
segment
like
there's
logic
in
there
for
rolling
the
segment.
B
C
D
Hi
well,
while
I
was
away
theoretically
some
prs,
where
some
of
my
pr's
were
emerged,
basically
mainly
the
scheduling
of
the
extraction
of
the
scheduling
of
scrap
scheduling
code
and
the
some
refactoring
dander.
D
D
A
C
This
week
I
modified
the
modified
the
multi-device
support
pr
as
sam
and
suggested,
and
I
also
implemented
the
pc
and
distance
placement
strategy
used
in
sprite
lfs
just
the
way,
as
the
paper
says,
and
I'm
now
trying
to
test
if
it
works
as
it's
supposed
to
be
in.
That's
all.
That's
all
for
me,
cool.
C
E
E
A
Okay,
everyone
or
anyone
else.