►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
EROFS, an Introduction and our Smartphone Practice - Xiang Gao, Huawei
EROFS filesystem is a Linux read-only file system in order to save extra storage space with guaranteed end-to-end performance for embedded devices, especially Android devices, which designs to reduce metadata compared with other generic filesystems and provide transparent compression support to target filesystem users. In the past year 2018, EROFS has been developed, merged into Linux staging tree and landed to several smartphones. Note that it is still actively under development and more useful features will be added later. This topic presents the issue and our practice of real-time decompression in consumer embedded devices, EROFS detailed design, benchmark, comparison with exist squashfs, compressed btrfs and the future roadmap of EROFS.
https://sched.co/Nru2
C
A
A
I'm
working
for
par
with
three
years
now
after
graduation,
and
mainly
in
OS
kernel
lab
and
mainly,
we
are
working
on
embedded
technologies
for
a
smartphone
and
I'm,
focusing
on
system
documentation,
for
example,
up
to
ever
before,
and
we
are
doing
the
fixing
of
box
and
I
also
provide
several
propose
propose
to
hallway
and
some
of
the
solutions
has
been
adopted
and
Aero.
Fs
is
a
random
take
to
name
and
well.
A
It's
not
a
big
issue
and
this
solution
to
meet
internal
requests
and
starting
from
here
annually,
I'm
gonna
do
some
upstream
work
regarding
the
storage,
and
so
every
year
we
will
have
requests
for
storage
organization.
So
this
is
what
we
do
yet
last
year
and
we're
meeting
demands
in
the
marketplace
and
the
largest
one
is
that
for
the
low-end
products,
some
of
the
16
gigabytes
are
still
making
feel
of
reason.
That's
targeting
for
developing
countries,
markets
and
the
storage
is
pretty
limited,
as
around
16
gigabytes
is
pretty
small
or
lower.
C
A
B
A
C
A
A
A
C
A
C
A
C
A
A
A
C
C
C
A
A
A
A
Google
has
really
optimized
squish
FS,
but
there
are
derpy
index
indexes,
that's
being
damaged,
so
that's
why
we're
not
doubting
the
FS
solution
and
finally,
we
raised
one
question
per
from
these
issues
with
encountered.
Is
there
any
other
ways
for
us
to
improve
the
performance
regarding
compression
and
decompression?
And
finally,
we
come
up
with
this.
A
A
C
A
This
the
density
has
been
proved
and
compression
rate
has
been
improved
accordingly.
So
for
most
of
the
I/o
cases,
we
can
get
a
smaller
sized
I/o
and
we
save
a
lot
of
I/o
and
convert
it
for
the
computing
of
CPU
and
we
improve
the
performance
for
reading.
Somehow.
So
that's
why
we
choose
the
fixed
output
mechanism.
C
C
A
C
A
A
We
want
to
achieve
the
fixed
rates
output,
which
is
a
K,
and
so
we
can
deliver
for
k2
and
change
it
converted
to
a
K.
But
if
it's
okay
we
can
bring
it
to
12
K,
and
so
the
storage
rate
is
way
better
than
400
K
and
it's
around
a
K.
So
later
we
will
have
a
sequential
analysis.
Give
you
an
overview
and
we
can
make
a
comparison,
and
you
can
see
the
difference
so.
A
C
A
A
A
It
might
cause
some
interrupts
in
page
crash
and,
for
example,
if
we
choose
squash
FS,
then
we
choose
them
fixed
input,
our
for
K
and
then
de
round.
That
will
be
a
roughly
2%
of
compressed.
Data
of
the
original
file
are
added
in
the
pin
to
the
page
cache.
How
are
you
list
as
well
and
it's
hard
to
compressed
and
don't
know
directly
if
some
of
the
compressed
pages
are
reclaimed?
That
means
we're
gonna,
consume
all
more
memory
and
that's
bad
for
custom
experience.
A
If
we
are
putting
in
oh,
are
you:
how
are
you
list
if
we
add
a
lot
of
this
documents
into
it
compared
with
the
uncompressed
parts,
then
we
cut,
we
are
causing
disruption
and
that's
past
number
one
and
number
two.
If
it's
fixed
output
and
fixed
input,
some
of
the
compressed
data,
my
cross,
the
boundary
of
storage.
A
C
A
So,
if
we're
using
temporary
buffer,
there
is
one
major
issue
for
a
fixed
input
if
we
have
ready
to
be
used
data,
but
we
cannot
make
full
use
of
it.
So
this
is
the
very
important
topic.
So
if
we
using
fixed
output,
judging
from
the
compressed
block
this
4k
or
the
whole
compressed
block,
it
can
be
decompressed
fully
and
we
can
choose.
C
A
A
So
it's
random
selection
in
the
compression
process
and
second,
we
using
EFS
io,
and
this
first
block
is
fully
decompressed.
Then
we're
using
give
SRO
to
do
the
decompression
and
FS
are
all
are
basically
doing
multiplexing
and
avoiding
application
for
a
temporary
buffer
and
the
your
vessel
can
also
serve
who
are
doing
the
unsightly
combustion.
So
this
is
the
first
solution
that
we
can
adopt,
and
second
is
that
we
are,
we
can
do
synchronized
and
a
synchronized
decompression
and.
C
A
Soma
tube
pages
and
we
can
run
food
decompression,
that's
organization,
number
one
and
optimization
number
two
is
that
we,
if
we
choose
a
synchronized
or
synchronized
decompression,
the
major
difference
is
that
the
pages
will
get
after
the
question
and
we
have
a
synchronized
or
synchronized
read
ahead.
Then
we
would
choose
the
compression
or
decompression
strategies
accordingly
and
the
reader
had
interface
is
not
completed
yet
and
if
we
see
better
yields,
we
will
choose
this
solution.
A
A
We
are
doing
multiplexing
for
document
pages
and
first
we
discover
that
we're
needed.
We
have
two
reasons.
First,
when
we
do
the
cache
decompression,
just
like
squash
FS,
then
we'll
cause
interruption
in
caching.
Second,
we
have
got
a
request
for
reading
and
we're
still
waiting
for
IO
and,
if
we're
adapting
temporary
buffer
than
before
depressing
at
the
forty
compression,
we
will
not
release
this
IO
Payton
following
smartphones
are
focusing
on
making
photos.
It's
one
of
the
highlights
point.
The
workload
is
pretty
heavy
for
memory.
A
B
C
C
C
C
D
C
C
C
C
C
D
D
C
C
D
C
D
C
C
C
C
D
C
D
C
C
D
C
C
D
C
C
C
C
C
D
C
C
D
C
C
B
C
C
D
D
D
We
have
these
searching
applications,
but
I
cannot
tell
you.
The
name
of
the
application
is
started
upon
the
paper
and
see
not
the
newest.
The
later
data
is
just
the
data
for
the
landing
you
can
see.
The
miners
means
that
it
has
been
optimized
and
you
can
see
the
rate
here,
but
some
part
they
are
not
optimized.
D
C
D
C
D
D
We
support
R&D
for
yes,
optimizing
it
and
it
has
been
landed
in
the
version
after
nine
point,
zero
point
one
and
it
has
been
launched
into
the
market,
this
new
money
products,
so
the
employees
team
compression
will
be
used
in
your
new
product
and
I
hope
to
up
string
to
us
people,
but
we
need
time
and
hope
it
can
be
used
in
water
scenario
school.
So
my
to-do
list
is
here.
C
C
B
C
D
City
news:
yes,
it's
moving
very
fast,
so
for
the
reading
of
the
compress,
the
fire
blasts
and
time
walk
the
decompression.
Yes,
it
implants
the
time
of
decompression.
So
compare
the
two
est
advantage.
Yes,
with
certainty
compression
rate,
you
can
see
that
the
compression
rate
is
about
it's
about
a
50
60
%,
compress.
D
B
C
D
C
B
D
The
different
that
compress
the
block
who
can
tell
the
is
the
compression
rate
Oh
rather
in
the
rate
is
within
our
reach.
Then
we
will
try
to
compress
it.
Yes,
we
will
try
to
compress
some
part
of
the
file
and
then
try
not
to
compress
some
part
of
the
park.
Yes,
you
are
trying
to
figure
out
the
whether
you
can
compress
it
ahead.
Yes,
and
we
have
this
effect,
is
there
some
extension
name?
We.