►
From YouTube: Ceph RGW Refactoring Meeting 2023-06-28
Description
Join us every Wednesday for the Ceph RGW Refactoring meeting: https://ceph.io/en/community/meetups
Ceph website: https://ceph.io
Ceph blog: https://ceph.io/en/news/blog/
Contribute to Ceph: https://ceph.io/en/developers/contribute
What is Ceph: https://ceph.io/en/discover/
A
All
right
welcome
everybody.
You
can
find
the
link
to
the
agenda
and
chat.
I've
got
a
couple
so
far.
First,
just
an
update
on
the
reef
release.
I'm,
currently
planning
to
consider
two
things:
blockers
for
the
rgw
component:
one
is
the
versioned
object,
consistency
issues
that
Corey
Snyder
has
been
working
on.
A
We're
going
to
need
those
to
merge
to
Reef
before
we
come
backward
to
Quincy
and
Pacific,
so
I,
don't
think
it
makes
any
sense
to
wait
for
the
first
Reef
Point
release
to
do
that
and
second
related
to
the
issue
with
corrupted
encrypted
encrypted
objects
in
multi-site
Marcus
identified
compression
as
another
potential
cause
for
that
before
the
reef
release,
support
for
encryption
and
compression
on
the
same
object
was
never
supported,
but
if
we
release
Reef,
as
is
this
would
be
a
regression
so
either
we're
going
to
have
to
disable
that
or
find
a
way
to
fix
replication.
A
In
that
case,
shelf
I
know
you've
been
tracking
failures
related
to
compression
and
multi-site
tests.
B
Right,
yeah
yeah:
it
has
nothing
to
do
with
multi-partlets
right,
but
it's
a
compression
and
encryption.
B
A
Yep
I
plan
to
raise
this
issue
with
Marcus
later
today
and
see
if
I
can
get
a.
A
A
We
can
move
on
then.
The
next
agenda
topic
is
about
the
async
request.
Refactoring,
we
just
recently
merged
a
pretty
big
PR
from
calpesh
that
extended
the
optional
yield
asynchrony
to
a
lot
more
call
paths
and
we've
essentially
have
a
plan
for
tackling
the
rest
of
them,
but
I
want
to
figure
out
a
way
to
get
regression
testing
into
theology,
so
that
we
can
first
of
all
confirm
that
we've
found
all
of
the
blocking
libretos
calls
and
also
prevent
us
from
adding
new
ones.
A
So
the
optional
yield
stuff
we
have
I
think
we
have
a
strategy
for
warning
on
blocking
OSD
requests,
but
there
are
other
places
that
we
could
block
like
on
conditioned
variables
or
HTTP
requests
or
other
things,
and
so
I
think
we
need
to
come
up
with
a
strategy
to
kind
of
audit
and
and
track
those
down.
Also.
C
So
when
I
commented
in
the
pr
is
that
we
can
try
to
check
that
at
compilation
time.
C
And
unless
you
want
to
make
sure
that
the
null
yield
is
not
passed,
so
if,
if
we're
passing
the
null
yield,
then
you
have
to
check
that
at
runtime.
C
But
if
your
check,
if,
if
you
just
want
to
to
make
sure
that
the
the
apis
with
the
option
yield
of
being
called,
you
can
check
that
compile.
And
why
do
we
need
to
told
you
for
that.
D
I
mean
we
do
want
to
check
that
the
null
yield
is
not
being
passed,
so
the
issue
is,
we
do
have
to
pass
null
yield
for
certain
things
like
things
called
from
rgw
admin
or
from
lib
rgw,
but
we
want
to
ensure
that
in
you
know,
rado's
TWD,
we
never
pass
a
null
yield.
A
Right
I
I
see
it
specifically
as
blocking
calls
from
azio
threads
like
the
Boost
front
ends
thread
pool
those
are
the
ones
where
we
don't
want
to
tie
up
an
entire
thread
and
the
the
logic
for
printing
those
warnings
uses
a
thread.
Local
variable
that
those
threads
set
specifically
to
request
the
warnings.
A
A
C
Yeah
I
guess:
there's
no
way
to
avoid
that
at
runtime.
You
just
runtime
is
a
big
headache
to
test
I
mean
if
you
have
a
couple
of
them
once
one
crashes,
you
have
to
fix
it
and
then
you
have
to
run
the
other
one
and
wait
for
the
other
one
to
crash.
C
And,
and,
and
also
you
might
miss
some
stuff
that
we
by
chance
didn't
cover
in
tutorial
or
didn't
cover
like
I'm,
not
sure
we're
going
to
run
the
entire
rgw
tautology
sets
test
switch,
which
is
huge,
so
I
I
think
there
could
be
a
way
to
figure
that
out
at
compile
time,
because
I
think
it's
all
compile
time
logic
right.
C
We
don't
have
somewhere
in
the
code
where
we
have
an
if
statement
dependent
on
some
Dynamic
value,
that
that
passes
a
null
yield
or
no
no
yield
different
places
in
the
code
different
specific
code
path,
they
pass
the
null
yield
or
not
and
I
think
that
could
be
figured
out
at
compile
time.
C
B
E
C
A
I,
it
might
be
possible
for
us
to
like
add
a
Constructor
to
the
null
yields.
Specifically
that
checks
the
thread
local
variable
or
I-
guess
it
would
be
the
optional
yield
Constructor
the
the
empty
Constructor
that
null
yield
uses.
B
A
Maybe
not
currently,
but
Adam
is
moving,
that
thread
pool
out
of
the
front
end,
making
it
available
for
other
things.
Oh.
F
C
C
So
if
we
are
from
some
reason
running
those
managers
or
initialize
those
thread
pools
in
places
that
we
don't
plan
on
using
them
or
we
don't
want
to
be
using
them,
then
maybe
maybe
this
is
something
else
but
I
mean
maybe
there's
a
maybe
that
what
I'm
trying
to
say,
maybe
the
static
way
to
figure
out
whether
not
whether
the
current
code
is
running
inside
boost
but
inside
beast
at
best
red,
but
I
mean
if
we
are
running
in,
let's
say
in
the
Daemon.
B
C
Well,
just
as
an
example,
let's
say
that
the
the
redis,
the
like
the
the
rgw
Damon,
has
like
an
initialization
sequence
and
all
that
stuff.
That
also
starts
the
the
front
ends
well.
At
that
point,
you
can
set
a
global
variable,
like
a
const
expert,
Global
variable
that
that
could
be
checked
in
this
in
the
empty
Constructor
of
the
of
the
optional
yield.
C
And
then
you
know,
if
you,
if
you
compiled
this
inside
or
together
with
the
together
with
the
the
rgw
Damon,
then
it
would.
It
would
assert
on
that.
D
So
there's
one
issue
that
I
don't
know
is
maybe
fixable
or
not
we're
currently
using
null
yield
explicitly
in
some
of
the
cell
drivers
that
are
not
Rhino
store,
so
posix
driver
uses
it
and
TV
store
uses
it,
for
example,
and
those
would
be
built
into
the
red
STW
demons.
A
C
A
Yeah
I
I
could
see
all
of
those
background
threads
being
asynchronous
and
running
on
the
same
thread,
pool
kind
of
in
the
in
the
far
future
when
we
have
time
to
rewrite
everything
but
kind
of
I
think
the
first
step
would
just
be
turning
the
warning
messages
into
assertions
in
the
tooth
allergy
environment
that
evolves
right.
A
That
doesn't
give
us
full
coverage
since
we're
not
our
tests
aren't
exercising
every
call
Path
from
request
threads,
but
if
we
do
miss
anything
and
block
on
one
of
these
front
end
threads,
then
that's
just
kind
of
a
performance
issue
rather
than
then
a
crash
during
run
time.
D
A
In
in
general,
weights
on
Ezio
thread
should
be
asynchronous.
A
A
C
C
There
was
at
one
point
something
I
discussed
with
with
Matt,
probably
an
idea
that
that
came
a
couple
of
times
and
this
is
to
to
create
a
memory
store,
but
the
rjw
mainly
for
the
sake
of
performance
testing,.
D
A
Well,
these
these
threads
are
just
calling
into
azio's,
I
o
context
run
function
and
the
I
o
contacts
kind
of
just
keeps
a
queue
of
work
to
do,
and
each
thread
will
pick
up
work
as
it
comes
in.
Oh.
A
Thread
pool
okay
right:
it's
it's
like
a
reactor
model
and
we
expect
kind
of
each
each
time
that
a
routine
resumes
some
thread
we'll
pick
it
up
and
and
run
the
continuation.
A
A
Yeah
so
I
know
that
Jason
dillerman
in
the
rgw
team
found
some
pretty
big
benefits
from
switching
to
neo-rados
and
I'm
eager
to
get
those
same
benefits,
but
it
doesn't
necessarily
need
to
block
the
the
work
on
reducing
thread
counts.
It
can
kind
of
happen
over
time.
F
Yeah
I
think
after
we
do,
what
do
you
call
it
after
we
do
the
data
sync
stuff
I
can
go
through
or
we
can
go
through
and
just
sort
of
do
just
do
it.
Piecewise
do
a
thread
by
thread
or
do
it
or
do
the
various
out
interfaces
that
sort
of
thing.
F
It
doesn't
necessarily
have
to
be
sequenced
behind
multi-site
per
se.
It
requires
some
of
the
same
stuff.
Multi-Site
requires
we
could
we
could
merge
that
stuff
in
and
then
you
know
like
there's
no
reason
once
we
get
those
pieces
once
we
get
many
of
those
pieces
merged
in
why
someone
couldn't
just
run
off
and
start
doing
that
independently,
while
I
finish
a
multi-site
yeah,
okay,.
F
E
F
So
I,
don't
I,
don't
actually
necessarily
think
the
the
I
don't
actually
necessarily
think
the
mixed
client
is
actually
a
problem
so
long
as
like
something
like
Sal
object
or
rjw
raw
object
is
the
common
currency,
like
you
can't
use
a
Neo
on
Neo
rados
handle
if
you
in
a
call
with
a
like.
F
E
F
E
I
see
that
you
probably
are
right
in
a
way,
but
we
also
did
going
back
to
the
numerito
sandals
alternate
universe
from
the
past.
Well,.
E
That
kind
of
that
kind
of
proved
that
there
was
serious
there
were
serious
problems
with
different
different
paths:
I
love,
that's
still
true,
but
but
seriously
I
mean
that
was
a
serious
proposal.
What,
if
what?
If?
What?
If
we
created
a
topic
Branch
to
do
this,
try
to
get
it
all
the
way
complete
and
passing
all
tasks
pulling
up
occasionally,
yeah.
E
A
A
So
Dan
you
mentioned
kind
of
the
issue
of
cell
drivers
and
support
for
optional
yield,
BB
stores,
specifically,
we
don't
really
have
at
least
with
SQL
Lite.
A
way
to
do
asynchronous
I
o
and
so
I
think
blocking
there
is,
is
just
going
to
be
the
default
always.
D
A
Yeah,
like
the
reads
and
writes,
can
obviously
be
async.
Some
like
directory
operations
unless
there's
a
way
to
use
IOU
ring
for
everything.
D
But
I
mean
things
like
X,
adders
and
stuff
will
probably
always
always
be
synchronous.
Sadly,
but.
E
F
A
Yeah
and
I
mean
the
other
option
is
if,
if
we're
using
a
back
end,
that
we
know
is
not
fully
asynchronous,
then
we
just
size
the
thread
pool
accordingly
and
be
okay
with
things
blocking
kind
of
how
we
currently
are
for
rados.
F
B
F
I
was
thinking
more
that
for
block
for
blocking
back
ends.
They
might
have
their
own
threat
tool
that
they
manage
rather
than
having
all
of
burritos
GW
deal
with
that,
so
that
we
would
have
so
that
they
would
effectively
enter
so
they
would
effectively
offer
a
non-blocking
interface,
but
would
do
their
own.
Something
blocking
calls
into
a
thread
pool
behind
the
scenes.
At
least
that
would
be
my
preference
for
how
to
handle
it.
E
E
F
F
E
I
mean
pretty
much
man,
it's
not
a
lot
of.
That's
not
positive.
I
only
want
this
stuff
works.
Just
we
want
to
do
it
in
a
way
that
doesn't
make
another
affordable
mess
in
our
w.
We
have
some
way
to
decide
how
to.
A
A
Always
going
to
be
a
cost
to
shipping
things
to
another
thread
and
and
so
I
think
there
will
be
a
lot
of
cases
where
it's
better
just
to
let
things
block
than
agree
then
pay
the
extra
overhead
all
right.
Well,
that
covers
all
the
things
that
I
had
on
the
agenda.
Any
other
thoughts
on
the
async
refactoring.