►
From YouTube: Ceph Performance Meeting 2020-10-01
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:
well,
let's
get
this
started,
I
guess
okay,
so
new
pr's
this
week
there
was
only
one
that
I
saw
from
igor.
This
is
more
work
on
his
optimization
of
pg
removal.
It
looks
like
this
is
part
one
and
two
of
two
that
might
be
an
update
to
his
his
previous
one.
That
was
also
submitted
a
little
while
back,
so
it
might
be
that
that
old
one
is
being
replaced.
I
guess
we'll
see.
So
that
was
the
only
new
pr
that
I
saw.
A
We
do
have
a
couple
of
updated
ones.
First
is
the
first
part
of
this
from
igor.
Also
there
was
a
stuff
volume
pr
to
retrieve
device
data
concurrently
that
was
reviewed
by
paul
paul
kuzner.
A
So
I
guess
that's
still
in
the
works
being
worked
on.
There's
this
pr
to
allow
dynamic
levels
in
roxdb.
This
does
not
actually
enable
them.
It's
just
changes
in
our
code
to
make
it
feasible
to
change
those
settings.
A
So
I
asked
for
some
performance
data
with
those
changes
in
place
and
using
some
kind
of
you
know,
setting
for
roxdb.
That
seems
same
for
for
doing
the
dynamic,
leveling
and
they're
working
on
submitting
some
results
for
that
pr,
so
that'll
be
very
interesting
to
see
what
they
see
with.
It
looks
like
more
testing
on
the
rgw
d3n
cache,
that's
still
just
kind
of
chugging
along
being
worked
on
and
then
majian
peng's
pr
to
reduce
buffer
list
rebuild.
A
I
think
both
igor
and
radic
have
been
looking
at
that
it
was
at
one
point
bailing
qa,
but
it
has
since
then
been
updated,
so
probably
needs
another
review
and
another
run
through
the
qa
suite
that
that
was
it.
As
far
as
I
saw
for
new
and
updated
prs
nothing
closed
this
week.
As
far
as
I
could
see
anything,
I
missed
guys.
A
All
right:
well,
then,
let's
move
on
so
in
the
last
couple
of
weeks,
gabby
has
been
working
on
building
a
prototype
for
recycling
the
the
keys
for
pg
log
entries.
A
This
was
an
idea
that
we
had
kind
of
had
for
a
while
that
we
were
hoping
was
going
to
be
good
and
it
turns
out
that
it
probably
isn't
what
we
saw
when
we
tried
it
out
was
that
we
end
up
in
a
situation
where
every
single
pg
log
and
update
ends
up
going
into
the
database,
and
we
have
significantly
higher
input
records,
significantly
more
work
being
done
during
compaction,
our
current
behavior,
while
it
does
introduce
a
lot
of
tombstones
into
the
right
ahead
log,
it
does
very
effectively
prevent
us
from
merging
lots
of
updates
into
the
database,
so
our
current
behavior
actually
is
not
as
bad
as
it
could
be.
A
It's
just
not
as
good
as
it
could
be
either
gabby.
Do
you
want
to
talk
a
little
bit
about
your
prototype
and
kind
of
things
that
you've
been
thinking.
A
B
Do
you
hear
me
now?
Yes,
there
you
go
better
now:
okay,
yeah!
The
mute
thing
was
a
problem
okay,
so
the
original
idea
was
that
instead
of
we
used
to
have
ever
incrementing
keys
every
time
the
version
the
e-version
was
the
key
and
the
e-version
are
just
monotonically
growing.
So
you
would
never
see
the
same
key.
The
same
key
again.
Every
transaction
had
a
unique
key
which
we
created
and
eventually
it
was
deleted.
B
Eventually
it
was
removed
and
a
tombstone
was
added
to
today's
sst
on
disk,
and
this
eventually
means
that
we've
been
allowed
to
flash
the
main
table
and
get
rid
of
the
writer
headlock.
That
was
the
old
design.
The
new
design
was
saying
you
know
what,
if
we
recycle
the
same
keys
and
and
I
just
created
a
mapping
table
from
the
e-version
to
an
internal
id
which
just
is
recycled
and
roxdb
never
saw
the
e-version.
B
It
just
saw
my
recycle
key,
so
we
kept
using
the
same
id
again
and
again
and
when
it
was
deleted,
it
was
asked
by
the
code
to
delete
it.
It
was
not
deleted.
Roxxdb
was
not
aware
that
we
deleted
this
thing
and
instead
we
just
created,
we
just
free
up
the
internal
id
and
later
it
was
assigned
to
a
new
request
which
generated
a
new
boot.
B
B
But
the
the
the
side
effect
with
the
end
predict
was
that
the
right
ahead
log
is
always
moving
forward
and
it
is
keeping
the
highest
version
of
the
mem
table
for
every
column,
family
that
is
using.
So
we
have
multiple
column,
families
and
the
version
or
sequence
number
sorry
is
incremented.
Every
time
you
flash
it
so
the
right
ahead.
B
Log
knows
that
you
have
ended
entries
from
those
main
tables
and
what's
the
highest
sequence
that
exists
and
when
the
mem
table
is
flashed,
then
we
create
a
new
right
ahead
table
and
right
ahead
right
ahead.
Log,
sorry
and
the
old
one
is
kept
aside
until
all
column
family
using
it
being
flushed,
and
since
we
never
called
flush
the
right
ahead.
Log
was
never
been
able
to
release,
so
it
kept
growing
and
growing
and
growing
until
it
reached
some
point.
B
When
you
say:
okay,
that
is
crazy
and
then
there
is
a
mechanism
in
works
to
be
saying
in
this
kind
of
scenario.
Let's
find
which
mem
table
we
should
force
flash,
and
the
idea
is
that
they
should
force
flash
the
oldest
one,
because
definitely
that
one
anything
which
is
older,
then
the
right
headlock
must
be
flash.
So
that's
how
we
end
up
flashing
the
main
table.
Even
so,
we
never
called
the
lit
it
was
still
flushed.
Nevertheless,
so
the
entries
were
flushed
and
stay
again
longer
there.
B
B
A
Do
you
guys
hear
me?
Yes,
your
video
is
gone
now,
but
still
here,
so
we
we.
B
The
reason
we
put
the
pg
log
in
that
that
in
rocks
db,
the
first
place
was
not
because
we
needed
to
be
persistent
database
object.
It's
because
we
needed
a
pg
log
to
go
to
some
kind
of
right
ahead.
Log
and
the
entries
tends
to
be
very
small,
and
our
thinking
at
the
time
was
that
if
every
object
we
just
issue
its
own
writing
to
the
log
or
you'll
see
a
lot
of
right.
Amplification
in
ssd
and
spinning
drive
will
just
say
very
slow
performance.
B
So
we
thought
we
should
be
able
to
aggregate
the
rights
with
the
pg.
Sorry,
with
the
object
node,
which
we
write
anyway,
we
knew
that
the
object
node
must
be
written
to
the
right
ahead
log.
So
we
said
you
know
what,
since
we're
writing
them,
let's
piggyback
the
the
pg
log
on
the
object,
not
the
right,
so
it
will
be
essentially
for
free.
I
think
that
was
the
thinking
and
we
do
get
a
free
meal
free
lunch
by
set
by
writing
into
the
right
ahead
log,
but
there's
no
such
thing
as
free
lunch.
B
So,
of
course,
we
end
up
paying
this
elsewhere
and
the
way
we
pay
it
is
all
the
extra
work
done
by
roxby
and
when
roxdb
is
writing
stuff
into
the
sst
tables.
Actually
the
t
is
a
relatable
is
writing
them
into
the
ssds
and
the
disk
and
eventually
creating
tombstones.
B
So
there's
a
lot
of
overhead
that
we
try
to
avoid,
but
we
still
want
to
use
the
right
ahead
log.
So
one
thinking
was
to
create
a
special
behavior
in
our
column,
family,
for
in
works
to
be,
and
we
could
mark
that
those
objects
never
need
to
go
to
disk
and
you
could
flash
them
by
flashing
the
main
table.
We
free
up
the
right
edit
log,
which
is
what
we
need,
but
we
wanted
roxdb
to
enable
flashing
the
mem
table
without
actually
writing
to
disk,
which
is
pretty
ugly
because
we
broke
the
semantic.
B
But
then
we
come
up
with
this
concept
saying
you
know
what,
if
we
mark
for
every
key
when
it
was
first
created
and
we
could
mark
this
key-
is
new.
It
was
first
created,
there
is
no
copy
on
disk
and
then,
if
it
is
deleted,
while
inside
the
right
ahead,
sorry
right
inside
the
main
table,
then
there's
no
reason
to
cure
the
tombstone,
because
we
know
that
doesn't
exist
on
disk.
B
B
But
we
said
you
know
what
in
this
scenario,
we
are
actually
adding
an
improvement,
because
we
at
the
market
that
this
key
was
generated
in
this.
It's
the
first
occurrence
of
this
key.
So
when
the
tombstone
is
going
down
down
down,
eventually
it's
going
to
meet
the
first
iteration
of
the
key.
It's
going
to
remove
it
and
the
tombstone
could
be
removed
as
well,
because
we
know
for
certain
there
are
no
version
other
version
of
this
key.
B
B
So
there's
two
problem
of
this:
the
first
immediate
problem
is:
can
we
convince
rocks
to
be
convince
them
to
actually
push
this
thing
upstream
or
would
they
refuse
to
take
it
and
we'll
have
to
keep
updating
our
copy?
Because
if
that's
the
case,
then
let's
do
the
simple
one
and
don't
bother
with
this.
B
C
B
It's
a
side
effect
by
multiple
layers,
but
yeah.
So
that's,
okay,
so
that's
one
direction
now
a
complete
different
direction
that
me
and
josh
discussed
about
a
week
ago
was
saying
you
know
what
let's
forget
about
roxby:
let's
try
to
get
the
pg
log
without
using
roxdb,
and
by
doing
that
we
don't
need
to
worry
about
roxy
b
and
we
think
we
can
actually
come
with
a
better
solution.
Sorry,
with
a
more
efficient
solution,
and
now
we
still
need
to
see
if
the
solution
is
covered
in
all
bases.
B
So
the
idea
was:
why
do
we
actually
need
a
pg
log?
I
mean
the
pg
log
is
not
essential
for
correctness.
B
It
is
needed
for
performance
without
a
pg
log,
when
there
is
with
the
osd
crashes,
we
need
to
scan
all
the
pgs
and
find
what
version
they
exist
and
if
they
need
to
be
synchronized
by
others.
So
the
peering
process
is
very
expensive.
B
A
B
B
A
B
So
then
we
start
saying
do:
can
we
maybe
minimize
sorry,
can
we
make
the
possibility
of
failure
extremely
unlikely,
and
so
so
there
is
going
to
be
one
scenario,
so
the
solution
we
suggested
or
discussed
is
not
covering
all
bases.
There
is
one.
There
is
one
scenario
in
which
we
will
still
need
to
do
the
full
disk
scan,
but
we
try
to
make
this
something
unlikely
to
happen.
So
the
idea
goes
like
this.
B
If
is
it
me
or
you
guys
appear?
Can
you
still
hear
me?
Yes,
okay,
okay,
so
what
you
said
is
that
this
we're
going
to
suggest
a
solution
which
is
going
to
work
as
long
as
at
least
one
member
survived
the
failure.
B
If
all
three
members
fail
in
the
same
time,
then
we
are
forced
to
go
to
the
free
pg
log
solution,
meaning
can
everything
and
hope
for
the
best,
but
other
than
that,
we
think
what
we
suggest
is
going
to
give
us
a
very
efficient
way
to
store
the
pg
log
without
compromising
anything
else.
So
the
idea
goes
like
this:
every
osd
member
is
going
to
maintain
double
memory.
B
Buffer
in
which
is
co
is
going
to
collect
the
pg
log
entries
once
the
pg
log
buffer
is
filled,
one
of
them
and
then
the
pigeon
logan
buffer
could
have
to
be
aligned
to
sector
boundaries,
so
you're
always
going
to
do
a
full
sector
right.
B
So
once
you
fill
a
sector
page,
you
name
it,
then
you
can
destage
it
single
right,
zero
right
amplification
and
since
you
have
double
buffer
now
you
have
the
second
buffer
you
could
use
and
you
always
need
to
know
what
what
version
you
have
in
a
pg
log
for
everyone.
But
this
thing
we
could
we
already
piggyback
on
every
io
that
the
that
the
primaries
and
the
replica
you
always
know
what's
the
latest
version.
So
as
long
as
one
of
them
survive
everybody
coming
back,
they
will
know
what
version
they
have.
B
Sorry,
the
surviving
would
know
what
version
they
have
and
they
have
all
the
pidgey
dogs.
So
you
say:
okay,
you
guys
have
to
roll
back
or
redo
everything
from
this
and
and
moving
forward.
So
by
communicating
with
the
surviving
members,
you
could
recover
the
equivalent
of
your
pidgey
lock,
but
this
thing,
of
course,
won't
work
if
all
three
of
them
disappear,
because
then
everything
have
to
be
scanned
and
paired
and
recovered.
So
the
question
is:
is
this
a
viable
solution.
B
A
A
A
A
We
may
it's
josh
here:
josh,
do
you
know,
is
that
something
telemetry
actually
we'll
collect
is
like
runtime
data
like
that.
D
D
Yeah,
just
going
back
to
the
idea
in
general,
I
think
the
the
concept
of
need
to
do
backfill
in
more
cases
isn't
isn't
bad.
I
mean
like
it's
describing
it,
so
it's
more
of
an
optimization
for
recovery.
A
lot
of
cases.
I
think
the
part
of
what
I
have
to
be
careful
about
is
making
sure
that
we
do
keep
the
correctness
of
the
recovery,
even
in
those
cases,
with
fewer
than
three
failures
too.
D
So
for
those
cases
we
do
need
to
write
like
some
things
down
to
disk,
for
the
transaction
to
be
complete.
So,
like
one
thing
we
could
try
to
do.
Potentially
is
piggyback
on
the
on
rocks,
cb's
right,
head
log
or
or
spread
that
right
ahead
log
to
write
down
just
the
for
any
information
that
we
need
from
the
pd
log
to
be
able
to
safely
determine
which
replicas
are
up
to
date
or
not,
perhaps
without.
B
D
Right
right,
so
the
object
node
already
has
this,
but
we
need
to
actually
if
we
want
to
use
the
object
node
for
that.
Instead,
it's
to
mean
to.
D
A
What
did
you
guys
when
you
were
talking?
Did
you
guys
at
all
talk
about
keeping
a
separate
blue
store
right
ahead
log
instead
of
trying
to
modify
roxdbs?
I
don't
think
we're
gonna
get
upstream
rock
stevie
changes
in.
Maybe
we
will,
but
I
I
think
the
likelihood
is
low.
So
I
keep
coming
back
to
wondering
if
we
need
our
own
right
ahead.
Log
and,
basically,
you
know
short
circuit
rocks
dbs.
D
I
think
we
definitely
wanted
to
have
a
single
right
head
log
to
avoid
transportation
from
trying
to
do
multiple
writes
that
are
often
pretty
small.
Do
you
think,
do
you
think
it's
more
feasible
to
get
rock
tb
to
like
store
its
radiator
logs
or
elsewhere,
then
to
modify
it
directly.
A
Well,
I
think
we
can
just
disable
rockstevie's
right
ahead.
Log
I've
seen
that
documented
in
various
places.
So
what
I
keep
coming
back
to
is
wondering
if
we
should
just
be
implementing
our
own
and
blue
store
and
then
that
also
makes
it
a
little
easier,
not
super
easy,
but
a
little
easier
to
do
other
back
ends
that
don't
have
right
ahead
logs
for
key
value.
A
B
A
A
D
Yeah,
so
I'd
be
concerned
that
if
we
disabled
write
a
log
entirely
for
rocks
to
be
it
could
get
into
a
state.
After
a
crash
where
we
couldn't
replay
with
the
knowledge
we
had
at
the
booster
level
and
get
to
the
same
state.
A
B
A
D
B
Mark,
I
I
think
one
possible
issue
is
that
roxtv
knows
when
it
can
release
the
right
headlock,
because
when
it
flashes
dice's
t
table,
then
you
could
find
out
which
right
the
headlocks
could
be
freed,
and
I
have
this
thing
we
don't
know
when
maintave
has
been
flashed,
I
mean
we
might
be
able
to
find
out,
but
by
default
something
will
miss.
A
B
A
I
actually
yeah.
B
B
Knows
when
to
flash,
because
when
it's
full,
it
knows
it's
time
to
flash
or
when
the
writer
headlocks
gets
full
and
so
on
and
so
forth.
But
when
you
take
over,
then
you
must
monitor
the
size
and
capacity
of
each
of
the
main
table
and
the
right
ahead.
Log,
which
is
part
of
what
rob
cb
is
doing
for
you.
A
In
the
chat
window,
I
just
push.
I
just
pasted
a
small
little
bit
from
their
blog
talking
about
my
rocks,
achieving
higher
performance
by
by
I
think
disabling.
The
automatic
flushing
behavior
of
the
right
ahead.
Log.
A
A
B
B
D
D
The
description
there
makes
it
sound
like
they're
doing
exactly
what
we
were
just
talking
about,
essentially
using
the
mysql
bin
log
as
the
right
head
log
for
everything
and
then
being
able
to
replay
things
from
that
and
therefore
not
eating
not
necessarily
needing
the
right
analog
from
rtb.
To
always
be.
D
A
B
A
A
A
So
maybe,
while
people
are
looking
around
at
this
stuff
or
reading
through
things,
the
other
thing
I
wanted
to
mention
is
that
in
that
spreadsheet
I
linked
earlier,
you
can
see
that
we
also
looked
at
the
existing
code
with
one
pg
log.
Entry
is
basically
setting
them
in
max
to
one
one
dupe
entry
setting
the
limit
there
to
one
and
then
both
of
those
together,
and
it
was
very
interesting
that
just
saying
the
pg
log
entry
to
one
didn't
have
a
very
big
effect.
A
We
saw
a
bigger
change
when
we
switched
to
a
single
dupe
entry
being
recorded
and
then
an
even
bigger
change
in
terms
of
input
records
when
we
did
both
of
those
things,
so
the
takeaway
that
I
saw
from
that
was
that
perhaps
there's
some
compounding
effect
there.
It's
also
possible
that
this
was
just
because
of
one
sample.
Maybe
maybe,
if
I
took
lots
of
samples,
we'd
see
you
know
different
behavior,
but.
D
Mark,
I
think
that's
that's
relates
to
how
the
two
pops
work
the
configuration
there
is,
if
you
change
the
pg
logs
size,
the
dew
pops
take
up
the
rest
of
the
space,
essentially
so
yeah.
D
You
have
three
thousand
total
entries
and
if
you
reduce
the
number
of
log
entries,
they
become
two
boundaries
instead,
so
the
I
would
expect
like
the
we
reduce
the
log
to
one.
You
have
the
same
number
of
input
records,
but
they
would
be
smaller
records.
B
Hey
gabby,
sorry:
what
were
you
saying?
No,
I'm
saying
what
josh
says
is
perfectly
aligned
with
your
finding,
because
when
you
set
the
pg
doctor,
one
the
result
were
almost
identical
to
the
default
behavior.
But
his
explanation
is:
is
that
you
still
doing
the
exact
the
exact
same
amount
of
of
trimming?
B
A
So
what
was
kind
of
interesting
about
that
right
is
that
with
one
pgp
log
entry,
one
dupe
entry,
we
actually
see
that
the
input
records
and
output
records
are
not
that
much
higher
than
when
we
completely
disable
pg
logo
map
or
pg
log
entirely.
It
actually
gets
pretty
close,
it's
not
quite
there,
but
it's
it's
a
lot
closer
than
our
current
default.
Behavior.
A
Still
slower
still
a
lot
of
overhead
in
the
pg
log,
we
and
that's
not
surprising,
it's
complicated.
It
does
a
lot
of
work,
so
our
upper
boundary
on
this
is
like
you
said
when
you're
looking
at
gabby,
I
think
about
40,
it's
a
little
less
than
that,
but
it's
it's
pretty
close,
but
given
our
current
code
and
other
bottlenecks
in
the
osd,
we
we
can
see
fairly
significant
gains
by
improving
this.
A
A
I
think
my
takeaway
from
that
is
that
is
still
a
valid
thing
to
do.
We
we
can
both
reduce
the
amount
of
wear
on
the
the
drive
by
improving
this,
and
we
can
improve
iops
and
and
just
guessing,
based
on
previous
testing.
That
will,
especially
if
we
can
improve
the
way
that
pg
log
itself
works.
We
can
reduce
the
the
amount
of
cpu
we're
taking
per
app
as
well.
B
So
we
consider
three
different
solutions
today,
which
might
so
one
of
them
is
changing,
rocks
to
be
adding
this
new
plug.
The
second
one
is
creating
something
completely
separate
for
just
for
the
pg
log,
a
new
solution
outside
works
to
be,
and
the
third
one
is
what
you
suggested
is
to
either
use
my
rock
instead
of
rocks
to
be
or
maybe
emulate
my
rock's
behavior
by
taking
control
over
the
right
ahead,
log
and
flashing,
so.
B
And
it
seems
interesting,
but
I
just
can't
through
it,
but
it
might
be
more
similar
to
what
we
need,
but
the
other
solution
is,
of
course,
what
you've
said
is
just
like
we
take
control
of
the
writer
headlock
and
with
the
controller
flashing
roxdb
would
never
know
about
the
right
headlock,
it's
something
that
we
maintain
internally,
but
we
need
to
know
that
everything
needed
for
roxdb
is
recorded
in
the
right
ahead
login.
B
D
I
think
that
does
sound
like
a
potentially
viewable
approach,
I'm
still
being
concerned
about
rocks,
db's
internal
state
and
and
according
to
the
probability
with
the
right,
headlog
or
end.
D
Yeah
then
good,
let's
understand
more
about
what
what
like
the
the
maximization
is
doing
there.
How
it's
been
log
works
nicely.
A
Well,
I
I
guess
the
one
of
the
big
ones
right
that
that
this
recycle
log
id
testing
showed
us
was
that
the
the
the
fact
that
we
can
tombstone
lots
of
entries
is
actually
you
know,
really
beneficial
right.
So
that's
that's
kind
of
the
part
of
the
current
free
lunch
that
we
get
is
that
we
actually
are
making
very
heavy
use
of
that
in
these
test
results.
Master
default
versus
recycle
log
id
default.
A
So
there's
still
room
for
improvement,
but
it's
it
is
doing
something.
I
don't
know
what
else.
What
else
right.
C
Yeah
remind
me
well
when
you
said
completely
getting
rid
of
pg
log.
Did
you
just
like
you
know,
remove
that
implementation,
or
did
you
just
get
rid
of
the
pg
log
by
means
of
like
making
the
pg
log
and
to
extract
all
zero?
How
how
did
you
implement
getting
rid
of
the
pg
log.
A
A
A
D
Yeah,
I
think
that'll
help
us
understand
whether
it
makes
sense
to
even
look
at
this
idea
of
maintaining
the
well
outside
of
box
db
or
not.
A
Caligan,
I'm
not
sure
if
I'm
saying
you're
right
a
small
datum
and
he
may
be
a
very
good
person
to
talk
to.
A
A
C
C
Well,
how
do
we
do
while
we
think
of
a
bigger
implementation
which
might
take
some
exploration
and
time?
Can
we
bridge
the
gap
between
like
where
we
have
one
pg
log
entry,
one
loop
and
the
default?
C
Can
we
get
to
somewhere
in
the
middle
by
I
know
we
need
to
track
two
pops
for
correctness
purposes,
so,
first,
a
test
by
reducing
the
dew
pops
and
also
reducing
pg
log
length
to
a
lower
value
which
I
think
doesn't
have
any
correctness
issues.
Just
as
we
said
it
is
an
optimization
for
recovery
purposes
and
see
how
how
you
know
how
much
better
we
can
get
with
just
making
those
small
changes
as
as
we
you
know,
get
to
the
bigger
picture
things.
A
D
Yeah
I
mean
the
dew.
Pops
are
our
practice
thing,
so
reducing
the
number.
There
increases
the
probability
that
you
run
into
a
problem
I'll
be
playing,
I'm
not
important
rights,
but
but
it
is
a
you
know,
a
trade-off
of
probability
of
getting
bad
rate
versus
the
x-ray
over
doing.
E
C
Yeah,
I
I
remember
in
the
past
when
we
had
some
issues
where,
due
to
not
enough
to
pop
tracking,
we
saw
out
of
order
issues
and
stuff,
but
I
I
think
the
real
question
is
what
is
an
optimal.
C
D
Yeah,
that's
something
I
think
we
haven't
really.
We
can't
it's
hard
to
know
for,
like
our
all
workloads
like
we
just
what
we've
chosen
today
happens
to
work
well
in
our
test
environments
and
in
our
use
of
environments.
It's
hard
to
know.
If
we
reduce
that
say
by
half,
would
we
still
be
okay
or
will
we
see
correctness
issues
in
some
cases,
so
we
wouldn't
today.
A
Josh
does
a
scale
with
the
speed
that
you
can
process
things
like
does
that
do
we
need
a
higher
number
of
a
higher
amount
of
do
bops
tracking
if
we
have
a
higher
ingest.
D
D
A
D
B
B
Josh?
What
about
your
idea
about
piggybacking
the
pg
log
information
on
the
object?
Node
itself?
So
we
don't
have
double
entries
so
that
because
the
vast
majority
of
the
information
in
the
object
in
the
pidgey
log
is
already
in
the
object
node.
So
if
we
just
add
this
extra
information,
so
we're
going
to
make
the
object,
node
bigger
and
we
could
stripe
it
back
when
we
read
them
from
disk.
D
D
B
D
B
D
B
B
You
take
all
the
extra
information
which
the
pidgey
dog
has.
It
doesn't
exist
in
the
object.
Now
then
push
it
inside
the
object
node,
but
only
in
the
disk
copy.
You
don't
have
to
put
it
in
the
memory,
then
roxtp
would
have
half
as
many
object
to
manage,
and
the
compaction
operation
would
deal
with
half
as
many
of
them
and
anyway,
the
vast
majority
of
the
data
is
repeating
himself.
So
even
the
right
would
be
shorter.
D
Yeah,
I
think
I
think
we
still
want
the
pg
login
memory
for
in
that,
in
that
case,
to
deal
with
like
network
failures
and
and
and
appearing
so
we
wouldn't
have
to
scan
that
scan
the
the
disk
for
like
transiting
issues
that
just
caused
a
little
bit
of
flapping,
but
for
any
any
kind
of
process.
We
start
when
we
actually
come
up
again.
I
think
we
think
we
could
get
the
information
about
which
objects
recently
changed
from
the
right
head.
Log
and.
D
No,
no,
I'm
not
saying
that
I'd
say
we
would
want
for
to
be
able
to
handle
temporary
network
clips
or
other
failures
where
we
have
some
kind
of
that
was
used
for
running,
but
they're
like
the
acting
site
changes
for
some
reason.
D
We
still
want
to
the
one
that
we
just
want
to
keep
the
pg
dog
in
memory
just
to
be
able
to
very
quickly
determine
what
what
we
need
to
do.
What
we
need
to
recover.
B
D
Adding
that
extra
info
to
the
I
mean
essentially
in
this
case
we
at
that
point
when
we
need
to
do
the
scan.
B
B
Do
we
always
have
one
object,
node
and
one
page
log
going
together,
or
can
they
be
original
in
different
order
or
in.
D
Yeah
there's
a
lot
of
overlap.
I
think
the
pg
has
a
little
bit
extra
information
about
like
what
type
of
operation
it
was
and
that
we
could
add
that
and
and
which
extents
were
modified.
We
could
add.
D
Different
levels
of
those
traction
right
that
the
pe
plug
is
is
being
modified
at
the
oc
layer,
whereas
the
owner
is
being
modified
at
the
booster
layer
today.
D
B
D
B
Yeah
right
I
mean
yeah,
so
this
is
the
problem
because
we've
with
the
pg
log,
you
have
direct
control
on
when
to
remove
them.
D
B
B
B
B
B
Right,
if
we
can
be
enough,
we
might
have
enough
entries
in
the
right-hand
lobe
we
could
actually
control
the
size
of
the
right-hand
log.
I
think
there's
some
parameters
to
say
it
might
be
just
defined
by
size.
I
don't
think
you
can
say
how
many
entries,
but
you
can
control
the
size.
So
if
you
set
the
size
to
something,
then
you
know
how
many
entries
you're
gonna
have,
or
you
can
say.
I
need
at
least
that
many
and
might
be
that
the
right
headlock
size
that
we
have
now
is
already
more
than
enough.
B
Sorry
take
it
back,
we
are
not
affected
by
the
right
headlock
size,
but
the
main
table
size,
because
when
the
main
table
is
being
flushed,
then
the
right
headlog
is
being
removed,
and
you
know
what
there
is
also
an
option
to
say:
keep
the
right
ahead
log
for
that
after
you,
you
discard
it.
You
can
ask
him
to
be
kept
for
some
time,
so
maybe
we
could
do
that
and
then
the
right
headlock
would
be
the
size
that
we
can.
B
B
I
think
what
they've
done
is
even
an
extra
optimization
to
what
we've
done,
because
we
are
now
trying
to
get
rid
of
the
pg
log
entries
cost.
I
think
they
try
to
get
the
whole
the
object,
this
stage
api
to
be
more
efficient.
Maybe
they
can
afford
to
be
a
bit
behind
which
could
happen
in
theory.
Just
imagine
if
you
make
yourself
a
plan-
and
you
say
you
know
what
I
know
that
I'm
going
to
be
right
in
this
16
object.
A
We
are
essentially
out
of
time
for
this
week.
That
is
this
a
good
place
to
stop.
Are
we?
We
have
things
on
our
homework
to
do
for
for
next
week.
I
think.
B
We
have
of
warm
works
to
do.
We
have
to
read
my
rocks
design
papers
and
see
why
they
did
things.
As
you
said,
we're
going
to
learn
a
lot
from
them.
A
All
right,
well,
maybe
that
gives
us
collectively
some
some
things
to
work
on,
as
we
can.
Is
this
a
good
topic
to
continue
next
week,
guys.
A
Good
all
right!
Well
then,
let's,
let's
for
those
interested,
let's
do
some
reading.
Let's
try
to
learn
something
in
the
next
week
here
and
then
we'll
we'll
we
discuss
next
week,
sound
good.
E
A
Well
then,
have
a
great
week,
everyone
and
we'll
we'll
meet
up
again
next
week.
Okay,
thanks
see,
you
guys
see
ya.