►
From YouTube: CNCF Storage SIG Meeting 2021-02-24
Description
CNCF Storage SIG Meeting 2021-02-24
A
Good
morning,
good
afternoon,
good
evening,
depending
where
you
are
we
will,
we
will
start
to
call
shortly
we'll
just
give
it
a
couple
more
minutes
to
to
allow
a
few
more
people
to
join.
B
B
A
All
right,
I
think
I
think
we
have
a
quorum.
So
the
first
item
on
today's
agenda
is
the
presentation
from
the
chavo
or
chubao.
Is
that
the
right
pronunciation,
fs
project,
which
is
currently
a
member
of
the
cncf
as
a
sandbox
project
and
they've,
made
some
amazing
progress
over
the
last
year
and
have
built
the
community
and
are
looking
now
to
move
into
incubation
stage.
So
we
look
forward
to
we
look
forward
to
the
presentation.
D
Okay,
hi
everyone
good
morning
evening,
okay,
so
this
is
shoreline
speaking,
I'm
the
co-maintainer
of
turbo
ifs.
So
today
I'm
going
to
present
on
behalf
of
troop
ios,
hoping
to
move
it
from
sandbox
to
incubation.
D
Can
you
see
my
desktop
yep?
Okay,.
E
D
As
you
may
recall
that
super
fs
was
formerly
described
as
a
distributed
file
system
when
it
was
first
open
sourced
and
presented
to
the
storage
sng
when
trying
to
trying
to
go
get
into
a
as
a
sandbox
project.
D
We
have
a
feature
added
to
the
project,
which
is
a
s3
compatible
interface.
So
the
using
scenario
expands
tremendously
after
that,
and
it
is
the
case
in
real
production.
D
It
is
already
beyond
the
scope
of
their
system,
so
we
prefer
to
create
a
distributed
storage
platform
right
now
and
what
makes
it
so
special
for
cloud
native
applications
here
are
some
challenges
we
summarized
based
on
our
experience
serving
applications
running
in
kubernetes
cluster.
D
It
is
impossible
for
us
to
deploy
different
cluster
wi-fi
clusters
for
each
customer,
so
multi-tenancy
is
a
necessary
feature
for
triple
fs,
and
I
think,
storage,
usage
and
throughput
is
hard
for
a
single
customer
is
hard
to
predict.
D
D
So
so
this
is
a
requirement
for
a
cloud
native
storage
platform
as
well,
and
since
we
have
a
lot
of
customers,
the
file
sizes
are
diverse,
ranging
from
kilobytes
to
terabytes,
which
means
we
have
to
support
both
large
and
small
cells.
D
D
So
these
are
the
challenges
we
taking
took
into
account
from
the
very
beginning
when
designing
a
survivors
project
to
solve
those
challenges.
There
are
some
key
features
listed
here
of
tobias,
for
example,
optimized
resource
utilization,
multi-tenancy
relaxation
and
scalability
for
metadata
and
the
data.
D
This
means
that
there
is
no
theoretical
limit
for
the
number
of
containerized
applications
using
the
same
truevivos
cluster.
D
D
It
is
used
in
production
at
gd.com
first
in
june,
2019
2018,
and
it
was
open
sourced.
In
march
2019.
D
The
the
industrial
paper
based
on
truffles
project
was
published
in
sigmoid
19
in
july.
D
In
order
to
integrate
with
more
cloud
native
ecosystem.
We
developed
super
fast
psi,
plugin
and
triple
fs
help
and
they
are
released
and
used
in
production.
Right
now,
in
december,
2019
roberts
joined
as
a
sandbox
project.
Then
in
april
2020
we
released
version
2.0,
which
supports
actually
a
compatible
interface.
D
Also,
there
are
several
external
users
listed
on
github,
the
most
recent
external
user
is
meizu,
which
is
a
consumer
electronic
company
in
china,
and
I'm
going
to
cover
the
new
using
scenario
of
different
companies
in
the
later
slides
and
in
august,
2020
oprah
joined
as
a
key
contributing
company,
as
we
know
that
such
projects,
such
storage
projects,
require
constant
investment
for
someone
to
be
able
to
make
key
contributions
or
key
improvements
to
the
project.
D
Then
we
have
a
plan
to
for
the
next
release
to
improve
their
stability
and
we
are
trying
to
to
support
more
of
big
data
applications
in
the
future.
D
As
you
can
see
from
the
diagram,
there
are
several
components
forming
the
whole
system,
which
is
resource
manager
to
manage
the
the
whole
resource
of
the
cluster
and
volumes
and
data
data.
Subsystem
is
at
the
place
where
failed
contents
are
actually
stored
and
the
meta
data
subsystem
is
where
fair
metadata
is
stored,
comparing
to
a
local
file
system.
A
resource
manager
is
where
fail
system
metadata
is
stored
and
the
metadata
is
where
a
fail
metadata
is
stored.
D
Okay,
and
to
take
the
request
from
application
and
users
and
resolve
them
into
meta
and
data
requests.
We
have
fused
client
and
object
node,
providing
both
bell
system
interface
and
s3
compatible
interface
respectively.
D
Here's
a
detailed
architecture
of
survivors
or
what
a
true
firefight
cluster
looks
like.
A
Hey
just
just
just
a
quick
question,
so
so
the
the
primary
way
of
accessing
a
volume
is
through
a
fuse
clients.
Therefore,.
D
Okay,
here's
what
drivers
cluster
looks
like
I'm
not
going
to
going
to
dive
into
the
technical
details
of
this
diagram,
but
I
think
there's
some
key
points
I
was
mentioning
first
of
all
is
that
the
metadata
is
highly
scalable.
D
So,
as
I
mentioned
before,
data
data
subsystem
is,
it
is
very
common
for
data
subsystem
to
be
scalable,
but
for
metadata
it
requires
a
design,
a
careful
design
source
for
metadata
to
be
very
scalable,
and
it
is
documented
in
in
our
industrial
paper
in
sick
mode.
D
D
Actually,
we
use
antiques
as
a
manager,
proxy
yeah.
It
takes
just
a
deal
with
other
reader
requests
because
that's
okay!
That's
where
the
bottlenecks!
That's
a
high
frequent
request
to
resource
manager.
D
And
thirdly,.
D
Oh,
as
you
can
see
that
one
clients,
the
control,
plane
and
data
plane
separated,
which
means
that
the
normal
read
or
write
process
does
not
go
through
resource
manager
or
manager
proxy.
D
It
only
goes
through
a
metanode
and
data
node
and
last,
but
not
the
least.
This.
This
architecture
can
withstand
a
high
traffic
peak,
which
is
very
useful
during
commercial
promotion,
festivals,
okay,.
A
So
we
just
just
sort
of
just
to
clarify
and
maybe
to
also
make
it
clear
to
others
so
so
effectively
the
data
part
for
any
files.
E
A
Objects
goes
to
the
data
nodes
and
it's
partitioned
and
sharded.
D
D
D
Actually,
yeah,
yes,
no!
No,
not
the
data
partition.
D
I
mean
class
gets
the
partition
field
and
in
order
to
access
a
single
file
first,
it
can
get
metadata
from
a
meta
node
and
it.
What
it
gets
is
a
data
partition
id
and
through
this
data
partition
id
it
can.
The
request
can
be
rotated
to
the
actual
data
node
yeah.
So.
F
Yeah,
in
fact,
I
have
a
question
regarding
so
you
say
that
it's
basically
the
metadata
you
have
trying
to
find
the
data
based
on
the
inode,
which
is
one
per
file,
so
that
that
means
that
you
have
to
have
the
like
the
data
node,
which
can
be
big
enough
to
fill
in
like
one
five
one
file.
So
every
files
the
file
cannot
be
shared
across
different
data
node
or
it's.
It
can
be
sharded.
G
F
D
It
can
be
charted
two
different
data
nodes,
because
the
minimum
data,
node
storage
unit
is
extent
and
a
large
file.
For
example,
a
large
file
can
consist
of
several
extents
and
this
extents
can
be
sharded
and
can
be
distributed
through
data
partitions
and
for
small
fails.
D
Maybe
a
white
extent
can
consist
of
several
files.
So
that's
why
we
I
said
I
said:
12s
is
optimized
for
small
cells,
because
small
files
are
aggregated
to
a
single
extent
and
so
for
small
files.
D
Several
files
can
be
aggregated
to
a
single
extent
for
large
cells.
One
large
valve
can
consist
of
several
extents
and
that
that
extents
can
be
distributed
through
data
partition.
F
Okay,
so
so,
what's
the
algorithm
or
strategy
we
use
to
distribute
or
decide
that
well
to
store
those
files,
or
is
that
my
name
because,
as
you
know,
staff
they
have
like
consistent,
hacking
and
stuff,
but
so
what
about?
What
we
have
here?.
D
Actually,
data
partition
can
be
marked
as
a
writable
or
read-only,
so
the
client
will
pick
a
one,
a
writable
data
partition
and
write
the
actual
data
to
to
specific
data
partition
and
update
the
method.
Node
update
the
metadata.
G
D
D
So
this
this
date
statistics
are
extracted
from
devstats.cncf.o.
The
data
is
before
versus
since
joining
sandbox
before
joining
sandbox.
The
duration
is
nearly
a
nine
months
and
since
joining
sandbox,
it's
about
14
or
15.
D
So
this
statistics
are
from
development
perspective.
As
you
can
see,
our
commits
increased
300
code,
committers
doubled
and
we
have
a
boost
for
pro
requests,
and
I
think
the
most
important
thing
here
is
that
now
we
have
two:
two
companies
constantly
in
in
invest
constantly
invest
on
this
project,
which,
which
is
gd.com
and
opel.
D
D
Okay,
I'm
going
to
brief
some
user
adoptions
from
different
companies.
First
of
all,
of
course,
jc.com
is
the
top
e-commerce
company
in
china,
and
it
still
has
the
largest
triple
fs
cluster
in
production.
D
And
then
opal,
there
are
several
using
scenarios
in
opel
right
now.
Some
of
them
are
already
in
production
and
some
are
under
development.
For
example,
drivers
served
as
the
back-end
storage
in
the
ai
platform.
D
D
For
example,
we
are
trying
to
use
tribalfs
as
a
backend
storage
in
a
data
lake
data
lake
architecture,
and
this
was
this
example,
development
and
also
we
are
trying
to
use
it
as
a
remote
spark
shuffle
a
plug-in
storage-
and
this
is
also
under
development
and
one
the
unwanted
usage
are
in
production.
We
plan
to
open
source
in
our
github,
and
also
it
is
a
consumer
electronics
company
in
china.
D
They
don't
have
a
development
team,
but
drivers
are
used
in
production
in
meizu.
There
are
several
business
customers
use
attributes
as
back-end
storage,
such
as
ad
algorithm
platform
and
database,
push
service,
risk,
control
and
cloud
backup.
A
Can
I
can
I
can
I
ask.
D
A
Are
they?
Are
they
therefore
kind
of
geared
towards
read
intensive
workloads
where
the
client
can
do
sort
of
lots
of
caching
or
or
are
they
or
or
are
some
of
the
workloads
also
sort
of
geared
towards
lots
of
right
activity,
and
the
reason
why
I'm
asking
this
is
because
you
know
there
are
some
obvious
gotchas
when
you're
doing
intensive
rights
with
with
fuse
file
systems,
for
example,
and
I
kind
of
wondered
if
you
had
done
anything
if
there
was
anything
specific
in
the
project
to
kind
of
deal
with
that.
D
Well,
actually,
we
may
have
to
find
a
balance
point
between
like
posix
file
system,
semantics
and
the
performance,
because,
as
we
all
know,
that
project
expel
system
semitics
are
not
very
suitable
for
for
distributed
storage.
So
we
have
to
make
some
compromise
about
the
project
semantics
to
to
balance
the
performance,
but
the
the
principle
is
that
we
had
to
fulfill
the
application
requirements
for
such
semantics.
Compromisation
like
one
to
cache
the
data
and
why
not
to
catch
the
data.
D
We
have
to
do
some
balance
and
the
principle
is
that
we
have
to
fulfill
applications
requirements.
So
as
long
as
we
can
support
the
customer
applications,
we
are,
we
can
release
the
project's
semantics.
A
Okay,
understood
rob,
esco,
wrote
up
question
in
the
chat
asking.
If
you
would
you
you
would
be
able
to
maybe
cover
what
motivated
oppo
and
jd.com
to
undertake
the
development
of
of
of
versus.
D
I'm
sorry,
the
development,
I'm
sorry.
C
Just
if
you
don't
mind
me
just
attempting
to
to
recast
the
question,
I
guess
how.
How
should
we
think
about
fs
and
apologies
if
I've
screwed
the
pronunciation
up
versus
other
fs
options
that
you
know
may
predate
it,
and
you
know
if
there
are
some
fundamental
limitations
that
could
be
adapted
for
the
use
cases.
C
D
Well,
actually,
the
main
advantage
of
tribal
fest
comparing
to
other
distributed
storage
is
that
it
can
support
a
small
files
very
well,
both
in
capacity
and
performance
wise
right,
I
think
I
mean
it's
very
hard
for
distributed
storage
to
support
small
fails,
so
this
is
a
big
advantage
also
for
for
large
sales.
Well,
I
think.
D
Everyone
has
a
similar
performance
regarding
large
sales,
but
for
small
fails.
Triple
fs
is
highly
scalable
and
is
optimized
specifically
for
small
fails.
But
of
course
there
are
some
scenarios
that
suppliers
cannot
support,
which
is,
I
think,
it's
my
circle.
I
circle
my
circle
directly
using
trouble.
Fs.
This
scenario
cannot
be
supported
right
now,
but
for
my
circle,
history
table,
which
requires
a
lot
of
a
read
a
request,
but
not
a
right
to
request
troubles
can
support
that
using
scenario.
D
Okay,
so
I
mean
what
what
I
mean
is
for
most
using
use
cases.
Drivers
can
support,
but
there's
certainly
some
database
scenario.
That
cannot
be
and
that's
what
we
are
going
to
cover
in
the
next
development.
D
Phase
does
that
answer
our
question.
C
I
I
think
it
gives
me
some
some
sort
of
direction
on
and
better
understanding
it
I'll
have
to
pour
through
your
docs
a
little
bit
better.
But
I
appreciate
it.
I
think
artelyn
had
a
sort
of
follow-up
question,
maybe
in
the
same
vein.
D
Actually,
we
have
a
performance
stats
in
the
paper
comparing
to
self-fs
and
well
I
I
I
didn't
bring
some
some
of
the
graph
here,
but
they
are
in
the
paper
and
you
can
find
it
on
github.
B
F
Sorry,
just
one
one
more
question,
so
you
mentioned
that
the
database
cannot
be
supported
or
like
mysql
cannot
be
supported.
What's
exactly
the
reason
because
of.
D
Logic
or
actually
a
magical,
masterclass
right
pattern
is
direct
l,
especially
for
innodb
storage.
Engine
innodb
storage
engine
uses
a
direct
io
as
as
a
is
right
header
for
direct
io.
There's,
really
nothing
a
fail
system
can
do
because
the
semantics
requires
the
I
o
to
be
sent
to
the
server
so
there's
well,
actually,
there's
no
I'll
say
no,
no.
G
D
For
the
file
system
to
do
optimizations
for
directional
red
requests,
so
what
we
want
to
do
to
support
direct
io
is
we
need
to
reduce
io
latency,
which
requires.
F
Yeah,
okay
has
no
room
for
yeah
yeah.
That's
basically
a
whole
become
a
performance
issue
right
so
because
they're
using
directional
they're
asking
the
file
to
be
persistent
so
become
a
crash,
persistent
right
so
based
on
your
current
design,
can
you
just
like
simply
send
the
content
to
the
backend
and
the
persistent
beer,
because
you
already
still
have
a
distributed
file
system?
It's
just
like
performance.
It's
not
that's
good,
but
in
theory,
if
you
back
past
your
cache
layer,
you
still
can
able
to
do
it
or
for
some
reasons
it's
it's.
D
Yeah
we
are
trying
to
to
cover
this
using
scenario.
Well
I
mean
direct
l.
Semantics
requires
the
I
o
to
be
sent
to
the
server,
but
so
if
we
can
reduce
the
network
network
latency
between
client
and
server,
then
we
may
be
able
to
support
this
scenario.
E
D
Actually,
we
have
a
strategy
to
select
data
nodes
and
if
there
is
a
strategy
that,
if
a
client,
if
they
know
the
available
data
nodes,
has
are
on
the
same
computer
node
of
clients,
then
it
will
choose
this
data
node
with
high
priority.
Actually,
we
have
such
a
strategy.
E
And
then
you
you
don't
charge,
then
you.
E
No,
no,
no
I'm
not
saying
don't
replicate,
I'm
saying
don't
shard,
then
you,
your
recast,
can
can
really
benefit
from
that.
D
Okay,
you're
all
welcome
to
I
discuss
technical
details
offline
and
to
to
to
issue
to
to
propose
some
issues
on
github,
yeah
you're.
All
very,
very,
very
welcome.
D
Okay,
so
here's
the
future
plan
I'm
going
to
cover
this
cover
these
plans
from
a
community
perspective
and
technical
perspective
for
community
perspective.
The
objectives
are
to
attract
more
companies
contributing
to
to
the
project,
and
we
are
going
to
make
it
easy
and
stable
to
use.
D
D
So
what
we
are
going
to
do
is
that
we
are
going
to
open
some
a
series
of
technical
lectures
to
which
can
do
some
source
code
analysis
for
someone
to
be
able
to
familiar
with
25s
more
quickly
and
we
are
going
to
pro.
We
can
also
provide
internships
for
college
students,
and
this
is
what
we
are
going
to
do
in
this
summer,
and
also
we
can
develop
tools
to
simplify
deployments
and
cluster
operations.
D
And
for
technical
plan,
where
we
are
planning
to
integrate
with
cncf
ecosystem.
D
It
is
highly
reliable
on
promises
and
we
are
going
to
integrate
with
book,
and
this
is
under
progress.
Well,
actually,
we
have
pro
proposed
a
pro
request
to
the
rook
community
and
we
are
waiting
for
the
feedback
and
also,
as
you
can
see,
we
are
trying
to
integrate
with
a
big
data
ecosystem
as
well,
for
example,
use
tribal
fs
as
back-end
storage
for
data
lake
and
develop
remote
spark
shuffle
service
planning,
and
we
are
also
going
to
the
next
biggest
feature-
is
across
zone
optimizations,
to
improve
robustness.
A
I
would,
I
would
just
like
to
ask
a
couple
of
questions
around
how
somebody
would,
if
somebody
wanted
to
run
this
in
production
today.
A
Are
there
you
know
until
sort
of
the
rook
changes
are,
are
committed?
How
how
would
somebody
sort
of
deploy
and
and
and
manage
this
across
sort
of
a
number
of
a
number
of
nodes
or
a
number
of
servers?
What
what's?
What's
the
what's,
the
sort
of
current
best
practice.
D
Well,
actually,
there
is
no
hardware
limit
to
deploy
to
buy
fs
for
best
practice.
I
think
I
can
give
some
suggestions,
which
is
a
resource
manager
can
be
deployed
separately
and
the
meta
node
and
the
data
node
can
be
deployed
hybridly,
because
a
meta
node
consumes
much
of
the
memory
resource
and
the
data
node
consumes
the
storage
resource
of
a
a
single
node,
so
they
can
be
deployed
hybridly
and
for
you.
A
Know
I
I
I
understood,
but
it's
I
guess
what
I'm
trying
to
get
at
is.
Is
there
some
sort
of
process
to
to
sort
of
automate
that
deployment,
and
perhaps
you
know
a
cluster?
You
know
like
a
for
example,
in
a
kubernetes
cluster
or
orchestrated
in
in
in
some
sort
of
way
or
where
is
this
something
that
you
install
on
a
sort
of
server
by
server
basis.
D
Well,
actually,
drivers
can
be
served
as
an
on-premise
storage
for
kubernetes
platform,
but
if
you
are
planning
to
deploy
a
trooper
fs
in
and
orchestrated
by
kubernetes,
I
think
first
of
all,
data
node
can
and
the
meta
node
cannot
be
migrated
from
different
between
different
nodes.
A
No,
I
I
I
think
I
understand
I,
I
understand
the
concept
of
the
of
the
data
node
and
the
and
the
method
partition.
I
I
guess
what
I'm
what
I'm
trying
to
understand
is
you
know
what
in
in
the
typical
use
cases
where
you
know
jt
or
oppo,
or
some
of
the
other
companies
that
are
using
it
in
production,
are?
Are
these
typically
deployed,
therefore,
on
you
know
some
sort
of
bare
metal
nodes
or
or
or
vms
or
something
but
but
is
it?
Is
it
under?
D
Well,
most
of
the
clusters
are
deployed
on
bare
metal
nodes,
and
can
it
is
served
as
an
on-premise
storage
platform
for
the
applications
running
in
kubernetes
cluster.
A
D
Yeah
but
as
we
have
a
survivor's
helm,
it
can
also
be
actually
it
can
be
deployed
and
orchestrated
by
kubernetes
cluster.
A
A
Were
there
any
other
fun
questions
for
for
sure.
A
A
A
Thank
you
thank
you
and
all
the
team,
all
the
project
team.
This
was
a
great
presentation.
I
think
we
all.
We
all
learned
a
lot
about
sugar
offers.
We.
We
also
had
another
agent
item
to
go
with
rafaela
to
discuss
the
cloud
native
dr,
but
I
I
think,
given
that
we
only
have
a
few
minutes
left
to
the
hour,
I'm
going
to
propose
that
we
that
we
move
that
to
the
next
call.
Hopefully
that's,
okay
with
you,
rafaela.
A
Indeed,
thanks
everyone.
Well,
in
that
case,
we'll
give
everybody
a
few
minutes
back
and
we'll
close
the
crawler
unless
there
is
any
other
things
that
anybody
else
wants
to
raise.
A
D
Thanks
have
a
nice
day.