►
From YouTube: Take Control of your Filesystems with containerd’s Snapshotters - Stephen Day, Docker, Inc.
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
Take Control of your Filesystems with containerd’s Snapshotters - Stephen Day, Docker, Inc. (Advanced Skill Level)
Containers have had uncanny abilities to build, manage, and distribute changes as part of the containers filesystems through the use of layers and graphdrivers. A critical part of the magic making people's experience with containers delightful, this is considered a necessity in any container-based system. The complexity and integration of graphdrivers makes working with them directly cumbersome and error prone. containerd departs from this and introduces a new abstraction, known as snapshotters. Mounting a container’s filesystem, direct manipulation, arbitrary diffing, and native copying, previously a challenge, are all now possible with minimal effort. In this talk, we'll cover the evolution of Docker graphdrivers to containerd snapshotters, demonstrating the wonderful properties of snapshotters in the process.
About Stephen
Stephen Day is a software engineer at Docker. His many contributions to Docker ecosystem projects include SwarmKit and the version 2 specification for the Docker Registry HTTP API, and evolving the available models for container image distribution. He currently works on containerd and as a maintainer of the OCI Image Specification.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
So
my
name
is
Steven
day
I'm
Steve
ooh
on
github,
and
this
is
take
control
of
your
file
system
with
snapshot
or
in
container
D.
That's
have
longer
title.
You
can
see
it
on
the
thing,
but
I
wanted
to
look
nice
on
the
slide,
so
so
I
guess
I
guess
the
question
this
is.
This
is
the
first
time
I've,
given
this
talk
and
I
want
to
give
this
talk
a
long
time.
It's
the
first
time
it's
got
accepted
and
so
I
apologize,
if
it's
not
great,
but
hopefully
we
can
get
through
it.
A
But
the
reason
I
want
to
give
this
talk
is
I
want
to
provide
a
rough
history
of
container
file
systems
and
the
important
parts
and
the
way
I
see
it
and
I'd
like
to
also
introduce
the
this
really
cool
functionality
built
in
container
D.
That
I
think
has
a
lot
of
potential
called
snapshot
and
I'd
like
to
kind
of
show
it
in
detail
and
and
what
some
of
the
basic
primitives
are
and
how
they
can
be
used,
and
then
somebody
who's
more
creative
than
me
can
run
with
that.
A
So
yeah
and
so
I
mean
the
two
areas
that
I
think
it's
it's
interesting
in
is
for
builders,
and
it's
already
being
snapchatters
are
already
being
employed
in
build
kit,
and
then
volume,
snapshotting
and
hopefully
I
can
show
you
why
and
prove
to
you
through
the
talk.
So
thank
you
so
the
other
thing
I'd
like
to
address
before
talking
about
this
is,
is
you
know
why?
A
Why
do
we
have
all
this
complexity
and
file
systems
and
you'll
start
seeing
it
as
I
talk
about
some
of
the
things
over
a
like
how
docker
is
built
up
and
then
how
we?
The
changes
we
made
in
container
D
and
the
whole
goal
here,
is
just
to
build
a
root
filesystem
for
a
container,
and
you
know
it's
it's
wildly
complex,
but
when
you
start
going
through
all
the
parts
they're
all
there
for
a
good
reason,
but
the
biggest
reason
is
to
reduce
the
storage
requirements
and
increase
workload
density.
A
This
is
this
is
the
the
the
main,
the
main
concept
that
we're
looking
to
do.
So
you
know
if
I
had
a
naive
model
and
I
just
unpacked
everything
on
a
container
file
and
I
have
storage
for
each
of
my
containers.
My
storage
cost
is
oh,
oh,
then,
in
the
number
of
containers
so
like
let's
say,
I'm
running
10
new
boon,
twos
I
have
to
run
ten
new
boon
to
ISOs
and
they
all
have
to
be
independent.
A
So
what
we
really
want
to
do
with
containers
is
so
we
don't
have
to
have
as
many
disks
and
we
can
use
most
of
that
disk
space
for
like
application
storage
is
we
want
to
converge
to
so
all
the
containers
use
the
same
storage
and
they're
using
the
same
data,
and
our
storage
cost
is
o
of
one
with
the
number
of
containers
that
are
running
the
same
file
system.
So
this
is.
This
is
the
whole
problem,
and
this
is
why
you
see
all
the
complexity.
This
is
why
you
see
this.
A
A
So
hopefully,
like
these,
these
we've
developed
a
model
that
actually
applies
to
different
systems
and
in
different
places,
and
even
they
don't,
even
though
they
don't
have
mounts,
we
can
still
use
the
terminology
mounts
and
we
actually
I'll
explain
later
about
how
we
use
the
terminology
and
mounts
and
container
D
and
how
that
can
apply
to
systems
that
don't
even
have
a
mount
syscall
per
se.
So
the
the
the
other,
the
other
big
concept
we
will
see
and
I
hope
people
have
seen
union
file
systems.
You
know,
file
systems.
A
Are
this
concept
where
you
can
take
two
separate
directories
and
then
overlay
them
together
and
then
create
a
mount
parametrized
as
overlay
and
then
see
both
of
those
things.
So
in
this
example,
I
have
a
layer,
0
and
a
layer,
1
layer.
0
is
my
base
layer
in
this
example,
or
whichever
way
the
air
is,
it
doesn't
doesn't
matter
too
much,
but
they
merged
together.
Like
layer,
0
has
been
layer,
one
has
lib
and
they
merged
together,
and
you
have
been
in
lib
how
those
things
merged
together
is
another
story
and
I'm
not
gonna.
A
Go
into
that
in
this
talk
at
all,
because
it's
complex
and
there's
good
kernel,
documentation,
kind
of
and
you
can
play
with
it
and
understand
how
that
behaves,
but
there's
a
whole
bunch
of
different
models
to
do
it.
So
I
I,
don't
know
if
this
is
right,
but
I
think
the
first
place
we
saw
Union
file
systems
was
maybe
plan.
A
What
is
the
current
one
that
everybody
uses
and
I
think
it's
called
the
overlay
to
driver
you've
probably
heard
about
that
at
some
point,
so
the
other
kind
of
file
systems
that
we're
going
to
talk
about
today
and
in
kind
of
inspired
snapshot
or
in
container
D
is
snapshotting
file
systems
and
I
struggled
to
drawing
this
diagram.
But
the
idea
is
that
you
have
a
single
like
volume,
which
is
just
a
collection
of
data,
and
you
can
pull
off
these
pointers
from
it.
And
so
you
can
say
well
revision,
zero
points
here
in
revision.
A
1
points
here
but
points
here
and
even
though
the
data
might
be
shared
that
that
hasn't
been
touched.
Yet
once
you
touch
that
data
it
Forks
off
and
that's
what
we
call
copy-on-write
and
both
in
both
Union
file
systems
and
snapshotting
file
systems,
typically
do
some
sort
of
a
form
of
copy-on-write,
but
with
snapshotting
file
systems.
A
They'll
typically
consolidate
data
storage
in
at
the
block
level,
so
you'll
have
some
sort
of
like
B
tree,
and
the
top
of
the
B
tree
will
point
in
to
either
like
revision,
0
and
revision
1
and
depending
on
which
tree
you're
in
you'll
be
able
to
see
bin
and
Lib
and
they'll
be,
but
they'll
be
completely
unique.
So,
as
you
do
modifications
to
these
two
things,
you
can
fork
them
off
in
different
directions.
A
Some
examples
of
this
are
again
with
the
plan.
Nine
folks,
like
fossil
NTFS
I
know,
has
some
snapshotting
support.
The
big
ones
now
are
ZFS
and
butter
FS,
and
then
everybody
uses
get.
Presumably
it's
not
a
file
system,
but
it's
a
very
similar
concept
of
kind
of
snapshotting,
where
I
have
like
a
commit
points
to
a
tree
and
then
that
tree
you
can
have
a
bunch
of
different
trees,
and
then
you
have
you
use
your
commits
to
define
the
relationships
of
the
changes
to
that
tree
over
time,
so
so
Union
versus
snapshot.
A
Why
am
I
talking
about
this?
You
know
what
one's
not
better
than
the
other.
They
have
different
properties.
They
have
different
behaviors
like
Union
file
systems,
for
instance.
They
allow
modification
of
underlying
data,
so
I
can
change
a
layer
at
the
mid
level,
and
so
I
can
like
do
an
upgrade
at
one
point
and
then
have
everything
else
consumed
from
that,
whereas,
like
snapshots
are,
are
more
static
but
because,
because
of
the
properties
of
snapshots,
they
can
typically
handle
more
revisions.
A
But
the
thing
is
both
of
them
are
copy-on-write
in
both
of
them,
for
containers
can
be
represented
with
a
shared
data
model
and
that's
kind
of,
and
that's
and
in
seeing
that
in
seeing
that
in
in
the
way
containers
behave
and
in
the
implementation
of
Dockers
graph
drivers
and
other
systems,
we
can
kind
of
define
a
common
way
of
saying,
okay.
Well,
let's
look
at
Union
file
systems
and
snapshot
file
systems.
That's
the
same
way
under
this
like
snapshot
model,
and
we
can
build
up
all
of
those
things
so
stepping
back
a
little
bit.
A
The
I
want
to
talk
about
the
the
docker
storage
architecture,
because
this
is
where
a
lot
of
this
came
from
and
in
it's
very
complex,
there's
like
a
demon
on
top
and
then
just
like
reference
store
and
it
references
images
and
those
images
have
like
image
configs
and
then
they
join
together
at
this
thing
called
a
lair
store
which
would
then
finally
gets
down
to
a
graph
driver.
And
if
you
ever
ever
looked
at
this
interface
inside
of
docker,
it
integrates
pretty
tightly
with
containers.
A
It
integrates
pretty
tightly
with
images
it
integrates
tightly
so
like
both
containers
and
images
have
references
into
the
graph
driver
and
the
graph
driver
actually
represents
those
IDs
directly.
So
it's
very
tightly
coupled
there,
you
can
do
plug
ability,
but
with
it,
but
all
of
your
life
cycle
is
tied
to
your
runtime,
with
the
containers
so
like.
These
are
some
of
the
problems
with
the
graph
driver
model
and
I'm.
Not
gonna,
go
too
deep
into
this,
but,
like
one
area
is,
is
it's
in
flexibility?
A
It's
really
hard
to
experiment
because,
like
you
want
to
experiment
with
file
systems
but
like
like
I'm,
more
of
a
filesystem
guy
than
a
container
guy
and
I
wanna
play
around
with
file
systems,
but
to
play
around
with
graph
drivers.
You
have
to
have
containers
stuff
so
and
so
it's
very
hard
to
experiment
with
new
models
that
that
might
be.
You
know,
take
a
few
minutes
to
implement
on
a
file
system,
but
once
you
start
getting
containers
involved,
it
becomes
more
complex.
A
The
other
thing
I
talked
about
a
little
bit
on
the
last
slide
is,
is
how
tightly
coupled
it
is
so
like.
The
container
life
cycle
is
an
example
if
you've
ever
ran
into
like
deadlocks
or
like
oh
I,
can't
remove
this
container
because
of
some
sort
of
references.
It's
because
of
this
massive
reference
network
inside
of
the
docker
daemon.
A
It's
also
really
tightly
coupled
with
the
image
format,
so
the
image
format
and
the
layers
are
actually
the
it's
defined
as
the
actual
on
disk
format
of
the
au,
FS
chainset.
So
there's
this
like
tar
file
in
the
middle.
That's
actually
just
you
just
tore
up
the
a
yo
FS
representation.
Well,
that's
really
efficient
and
its
really
great,
but
it
means
that
every
other
graph
driver
needs
to
convert
between
a
o
FS,
this,
a
u
FS
format
and
also
it
makes
it
hard
to
increment
on
image
format.
A
So,
like
you
can't
do
you
can't
say
well,
I
want
to
try
out
get
for
some
reason
or
I
want
to
try
out
a
new
tree
thing
or
something
like
that.
It's
a
lot
easier.
It's
really
really
hard
to
do
in
docker,
because
you're
so
tightly
integrated
with
that
format
and
then,
as
I
touched
on
before
is
the
primitive
is
just
can't
simply
can't
be
used
outside
containers
right.
A
So,
like
you
tied
that
lifecycle
so
you're
tied
to
using
containers,
so
stepping
back
I,
hopefully
I've
covered
most
much
of
the
words
I
just
want
to
say
what
container
D
is.
You
could
have
come
to
my
intro
talk
or
I'm
doing
another
deep
dive
on
Friday
and
you
can
learn
all
about
it.
You
can
come
and
say:
hey
what's
container
D
or
you
can
look
it
up
on
the
internet
whatever,
but
the
like
at
the
base
of
it.
A
It's
a
container
runtime
manager,
it
powers,
docker,
can
do
kubernetes,
CRI
stuff
and
but
provides
the
primitives
to
implement
containers
and
it
increments
on
the
internal
architecture
of
docker
and
provides
that
it's
got.
Colton
also
has
a
great
talk
on
container
d,
showing
what
it
can
do,
what
it's
capable
of
check
out
the
URL
container
d.
A
You
should
be
able
to
find
this
quite
easily
yes,
so
so
this
is
the
architecture
of
container
d
and
at
the
top
we
have
the
interfaces
like
g
RPC
and
in
the
middle
we
have
these
g
RPC
service,
RG,
RPC
and
prometheus
metrics,
and
then
in
the
middle.
We
have
all
of
our
services,
and
this
talk
is
really
going
to
talk
about
just
the
snapshot
in
in
in
how
that
integrates
with
the
storage
system,
but
really
just
more
about
snapchatters
and
what
they
do
and
how
they
work
and
the
lifecycle
and
how
we
represented
them.
A
So
this
diagram
is
just
very
just
the
simple
container
storage
architecture.
So
basically,
there
is
a
metadata
store
which
holds
like
containers
and
in
images
and
those
just
reference
out
to
snapshots
and
then
like
an
actual
image
content,
and
so
these
metadata
stores
actually
provide
the
linking
between
the
snapshots.
So
there's
so
like
you,
don't
identify
a
snapshot
based
on
the
image
you
pulled
it
with
you
just
say
this
snapshot.
Has
this
ID
and
I
have
an
image
record
that
points
to
this
ID
and
you
and,
however,
you
want
to
build
that
relationship.
A
You
can
do
it
doesn't
matter.
The
the
IDs
and
the
snap
shutters
are
completely
opaque
like
weak.
So
all
of
this
these
are
based
on
simple
layer
relationships.
So,
like
you
make
a
change
you
you
you
make
some
or
you
pull
off
a
layer.
You
make
some
changes
to
it.
You
commit
back
your
changes
and
then
now
you
have
a
layer
relationship.
A
The
interface
is
much
smaller,
it's
much
more
focused
I,
don't
have
the
graph
driver
interface,
but
believe
me,
it's
large
and
we,
you
know,
like
I,
said
before
non
updated,
non
opinionated,
string,
keys
and
then
the
biggest
piece
I
think
will
improve
performance
and
behavior
under
a
lot
of
other
conditions.
Is
the
fact
that
we've
externalized
the
mount
life
cycle
so
like
the
graph
drivers
and
docker
actually
perform
the
mounts.
A
So
you
say:
hey,
okay,
well,
mount
this
container
for
me
and
give
me
a
read/write
image,
and
then
you
say:
okay,
alright,
and
then
you
get
it
back
and
then
you
have
this
handle
and
then
you
got
to
make
sure
to
unmount
that
handle,
whereas
with
the
snap
shutters
what
you
get
is
just
a
mount.
You
get.
A
This,
like
this
reference
object
and
you
can
then
mount
the
filesystem
as
you
see
fit,
and
so
now
you
can
tie
it
to
the
lifecycle
of
the
thing
that
you're
actually
using
it
with,
which
is
typically
a
container,
could
be
a
build.
We
also
support
something
called
leases
within
container
D,
so
you
can
define
like
a
transaction
for
when
this
snapshot
is
actually
available.
A
So,
like
I,
said,
there's
no
mounting
there's
no
actual
mounting
it
just
returns
mounts
so
you
can
do
it
in
user
space.
You
can
do
all
sorts
of
other
cool
stuff.
You
don't
actually
have
to
do
a
Cisco
mount
they
could
be.
You
could
have
a
snapshot
er
that
implements
URLs
when
it
does
something
with
URLs
or
something
like
that.
You'd
have
to
have
special
mount
support
for
that,
but
you
can
do
that.
They're,
always
explicitly
active
and
explicitly
committed.
A
So
there's
a
life
cycle
and
I
and
I'll
show
you
that
and
then
all
the
life
cycle
is
represented
by
a
command
and-
and
so
it's
very
easy
to
use
very
simple
there's.
No,
you
don't
get
back
an
object
for
each
snapshot
and
that
ensures
that
you
don't
have
these
like
arbitrary
life
cycles.
They
can
kind
of
get
in
the
way
and
then
the
referent
reference
keys
are
chosen
by
the
the
callers
and
we
don't
actually
integrate
any
of
the
formats.
A
All
of
the
dipping
that
you
would
do
in
docker
to
get
images
or
in
layers
within
docker
are
is,
is
completely
external
to
the
snap
shutters,
so
I
can
define
completely
new
image
formats,
but
still
use
snap
shutters
with
them,
and
we
provide
lots
of
libraries
to
do
that.
Conversely,
our
diff
system
doesn't
require
you
to
use
snap
shutters,
so
you
can
just
take
two
arbitrary
directory
paths
on
the
filesystem
and
then
dip
them
and
generate
a
layer.
So
you
can
you
can
you
can
build
a
lot
of
primitives
from
that?
A
So
this
is
the
general
snapshot
light
cycle,
and
hopefully
this
little.
This
isn't
too
opaque.
But
on
the
so
the
first
step
here
is:
we
have
a
committed
p0
and
then
we
call
prepare
on
it
and
we
give
it
a
name
a
and
then
you
have
a
and
then
you
can
do
things
to
it.
On
that
arrow
going
down
to
a
prime
and
then
you
have
a
prime
and
you
call
commit
on
it
and
that
will
create
p1
and
then
create
this
little.
A
A
So
is
that
that's
pretty
clear,
so
here's
here's
like
an
example
and
I'm
gonna
do
this
in
a
demo
here
in
a
moment,
I've
done
this
demo
live
yet
so
hopefully
it
works
so
in
in
in
in
in
this
one,
we're
basically
saying:
okay
well
with
prepare
we're
gonna
call
it
active
zero
because
it's
gonna
be
in
the
active
state
and
then
we're
gonna
actually
mount
it.
So
we're
gonna
mount
active,
zero
onto
a
a
location
on
the
disk
and
then
we'll
touch
hello.
A
That's
missing
some
some
path
stuff,
but
it
should
be
target,
slash,
hello,
but
and
then
we'll
unmount
the
target
and
then
we'll
commit
that
back
in
and
then
we
have
a
snapshot.
So
then
we
can
investigate
that.
So
we
can
list
these
snapshots.
We
can
do
a
tree
on
it,
I
don't
know
if
you
ever
saw
doc
or
tree.
It
was
a
very
cool
command
but
had
a
lot
of
internal
problems
because
the
way
docker
is
built.
We
can
support
that
directly
with
snapshots.
It's
really
useful,
really
cool
to
look
at
and
I'll
show.
A
You
I'll
show
you
a
few
examples
about
it
here
in
a
moment,
and
then
we
have
a
mounts
command.
So
I
can
so
like
I
can
run
a
container
and
then
I
can
stop
it
and
I
can
mount
it
outside
of
the
container
I
can
fiddle
with
it,
and
I
can
unmount
it
and
I
can
start
the
container
up
with
it
with
those
changes.
A
So
you
can
imagine
all
sorts
of
cool
stuff
you
can
do
with
build
and
some
some
op
there's
operational
things
you
could
do
you
could
you
could
grab
dumps
without
having
to
do
it
exact,
there's
a
lot
of
there's
a
lot
of
things.
So
hopefully,
let's
see,
let's,
let's
see
if
we
can
get
this
to
work
all
right,
so
I
have
an
empty
container
D
here
and
should
be
no
snapshots.
Okay,
great
so
we're
gonna
do
is
we're
gonna,
create
a
snapshot,
and
so
all
of
the
things
are
pretty
well-documented.
A
Here
we
have
like
commit
diff
info
and
I'll.
Show
you
show
you
how
this
relates
to
the
actual
internal
interfaces
here
in
a
second,
but
we
can
do
a
prepare
and
when
you
do
a
prepare
and
you
don't
give
it
a
parent,
it's
just
going
to
start
with
an
empty
directory.
So
we'll
call
this
active
zero.
Just
like
our
example
in
the
slides
and
okay,
it
works
sweet
all
right.
So
now
this
should
show
up,
and
we
see
that
we
have
active
zero
and
it
is
active
and
well
okay.
So
what
does
that
mean?
A
How
useful
is
that?
Well:
okay,
it's
not
that
useful!
Yet
so
I
have
a
temp
of
my
path
and
what
I'm
gonna
do
is
I'm
going
to
mount
this.
So
there's
a
CTR
snapshot,
mount
command
and
so
will
mount
on
temp
my
path
and
then
we
will
do
active,
zero,
oops,
zero,
and
so
actually
what
this
did.
Is
it
just
prints
the
mount
command,
I
I
didn't
want
to
build
an
actual
mounting
into
there.
A
So
just
give
you
the
command,
and
then
you
can
just
is
wildly
dangerous
thing
called
X
hogs
sudo,
if
it's
so
much
fun,
so
so
we'll
mount
that
and
we
can
actually
see
well,
okay,
it
doesn't
look
like
there's
anything.
It's
an
empty
directory.
I
already
already
was
forthcoming
about
that,
and
you
can
see
here
you
can
see
here.
That's
that's
the
mounting
of
it.
It's
it's
just!
It's
just
a
bind
mount
kind
of
right
now,
because
there's
no
changes
in
it,
but
we
can
do.
We
can
do
a.
A
What
did
I
say
here,
yeah
well,
yeah,
we'll
go
ahead
and
touch
so
we
can
do
a
touch,
so
we
can
do
you
know
pseudo
touch
temp
my
path,
hello,
and
then
we
can
see
that
in
our
in
our
path
and
let's
get
that,
let's
get
that
free
command
a
you
know,
working
nice,
okay.
So
so
now,
let's
unmount
that
so
we'll
unmount
a
temp,
my
path
and
we
you
know
we
have
to
tell
it
to
do
it.
You
know
hard
with
sudo
and
then
we
so
now.
What
do
we
have?
A
We
still
have
this
active
snapshot.
Nothing's
changed
about
the
snapshot.
It's
just
beyond
this
state,
so,
like
container
D
doesn't
know
about
this.
Yet
so
what
I'm
gonna
do
is
a
commit
command
and
a
commit
command
is.
Is
it's
just
like
it's
just
like
the
the
prepare
command
except
it's
kind
of
the
the
other
part
too,
and
I'll
show
a
code
example
about
how
this
works
in
a
more
complicated
scenario.
So
we
just
call
commit
and
then
now
we
could
list
our
snapshots
and
we
can
kind
of
see
what
happens
here.
A
Where
does
that
go
this?
And
you
can
see
here,
Oh
foo
has
been
committed
and
we
no
longer
have
our
file
system
path.
There
there's
nothing
there
because
we
unmelted
it.
So
what
we
can
do
next
is:
let's
create
another
one,
but
this
time
when
we
create
our
when
we
prepare,
we
are
going
to
define
foo
as
the
parent.
So
now
I
can
do
that
same
fancy
mount
command,
where'd
it
go,
wouldn't
amount.
Let
me
just
type
it
out:
CTR
snapshot
mount.
Then
it's
gonna
be
temp.
My
path
active
inactive
0.
A
This
is
we're
using
the
same
reference
as
before,
even
though
it's
a
different
one.
So
that's
our
mount
command
so
notice
that
it
changed
quite
a
bit
right.
So
now,
since
we're
actually
descending
from
foo,
we
actually
see
that
we
start
where
we
have
an
overlay
mount
and
you
can
see
it's
like
type
overlay
overlay
and
it
says
a
lot
lots
of
things.
A
It
defines
a
working
directory
lots
of
implementation,
details
about
overlay,
which
you
can
go
read
about
and
well
I
ran
out
again,
but
actually,
let's
do
the
fun
thing
and
pipe
it
to
X
argh
sudo.
So
so
now
we
have,
it
mounted,
there's
hello
and
we're
we're
back
to
it.
The
cool
thing
now
is:
we
can
do
a
CT,
our
snapshot
tree
and
we
can
see
like
oh
cool,
we
have
a
relationship
between
active,
zero
and
foo.
So
that's
you
know
we're
in
business.
A
A
So
now
I
can
go
and
I
can
do
the
same
kind
of
thing
where
I
touch
into
we're
gonna
touch
world
this
time
and
then
we
should
be
so.
We
should
see
tree
my
path
and
then
we
got
hello
and
world
and
then
we
can
go
ahead
and
unmount
that
and
my
path
whoops
got
to
tell
it
to
do
it
harder
than
that
and
then
and
then
we
can
do
a
commit.
So
CTR
snapshot
commit.
A
And
then
we'll
do
what's
the
ordering
here,
so
we're
going
to
commit
in
do
bar
and
then
we're
going
to
commit
active,
0,
active
0,
we're
gonna
commit
that
into
bar
and
then
now
what
happens
is
I
have.
So
if
we
look
at
snapshot
tree,
we
so
now
active
0
has
been
shut
down
because
we
committed
it
like
it.
A
Acts
like
active,
active
snapshots,
act
like
a
transaction
and
that
we've
committed
it
into
bar
and
if
we
list
that
and
when
we
look
at
that,
we
still
have
the
same
like
bar
has
foo
as
a
parent
and
they're
both
committed
snapshots,
and
so
it's
like
what
I
did
here
is
basically
built
up
a
container
file
system
from
scratch,
with
from
the
command
line,
so
I
think
it's
cool
okay,
so
so
moving
on
so
a
little
bit
so
the
internals.
So
if
you
can
see
that
ok,
so
so
this
is
the
interface
of
the
snapshot.
A
Err
and
I
have
a
link
to
it
at
the
end
and
if
you're,
if
you
really
want
to
understand
it
and
all
the
operations
go,
read
the
go
doc.
We
spent
a
lot
of
time
ensuring
the
model
was
up
to
snuff
and
well-defined,
but
we
have
but
the,
but
the
interface
has
is
mostly
method
driven.
You
can
see.
We
have
string
keys
everywhere
in
context,
but
the
in
that,
but
the
the
big
takeaway
here
is.
A
We
have
three
kinds:
the
with
the
active
and
committed
which
I
showed
you,
and
then
we
also
have
what
sort
of
called
views,
and
so
these
are
read-only
and
and
that
allows
snapchatters
to
say
well
if
it's
read-only
I
can
mount
it
differently
or
I
can
do
different
data
sharing.
So
we
know
that
modifications
aren't
going
to
come
through
and
you
can
actually
express
that
in
the
system
and
then
just
like
I
showed
you
on
the
command
line
with
the
snapshot
LS.
A
You
can
see
that
that
info
is
represented
in
this
structure,
and
so
we
can
actually
stack
these.
But
that
is
not
what
I
expected
to
do.
Okay,
so
we
can
actually
stack
these
and
get
back
the
info,
so
you
can
actually
build
up
so
that
tree
command.
What
it
does
is
it
walks
down
and
then
gets
all
the
info
struct
and
then
assembles
a
tree,
and
so
you
can
actually
see
the
relationships
inside
of
your
file
systems,
which
time
do
I
have
okay.
A
Everything
which
is
like
super
key
right
is
that
you
do
something
you
mount
it
and
then
you
unmount
it
that
way.
You
don't
have
all
these
mounts
hanging
around
your
system
and
causing
later
problems
for
you,
and
then
you
simply
take
that
and
you
you
commit
it
and
that's
it
and
and
so
and
then
you
can
apply
this
in
a
loop
and
that's
how
you
do
layered
ifs-
and
this
is
this-
is
writing
container
D
in
the
root
FS
package.
You're
curious.
A
It's
really
simple,
really
easy
to
understand,
and
it
it's
it's
quite
a
powerful
concept.
This
apply
function.
This
diff
not
apply.
Ur
is
implemented
to
deal
with
like
OCI
style
or
docker
style
containers,
but
you
could
do
almost
whatever
you
want
in
there
and
like
I,
was
just
doing
touches
on
the
file.
So
a
couple
of
considers
considerations
so
like
so
I
snapshots
are
a
generally
good
model.
It's
pretty
simple.
A
Hopefully
I've
explained
it
in
a
in
a
way
that
can
be
consumed,
but
I
think
we
have
a
really
good
model,
because
I
think
it
will
work
for
lots
of
different
scenarios
without
modifications
to
the
actual
snapchatters.
We
can
modify
things
around
the
snapshot
so
that
they'll
work
in
different
ways,
so
you
save
run
a
snapshot
or
inside
of
a
container
and
you
could
get
like
UID
mapping
so
for
rootless
I.
A
Don't
think
the
snapshot
model
needs
to
be
changed,
but
I
think
all
that
needs
to
be
done
is
how
you
actually
do
the
mounts
and
UID
mappings
that
do
present
problems
for
rootless
containers
and
I'm,
not
an
expert
in
that
area.
But
there
are
people
here.
You
can
probably
ask
questions
about
the
problems
that
might
come
up.
The
other
cool
thing
that
I
don't
think
anybody's
doing
yet,
but
would
be
great
and
we
can
help
out
with
is
daemon
lists,
snapshot
or
so
like.
This
is
just
a
snapshot
package.
A
There's
a
test
suite
you
can
just
import
it
and
play
with
them
and
go
and
and
do
snapshotting
without
the
daemon
and
so
I
think.
There's
definitely
applications
for
builders
that
they're,
based
on
like
native
snapshot,
ORS
and
stuff,
like
that,
so
there's
lots
of
interesting
things.
I
think
that
can
be
built
here.
I
think
that
you
could
build
a
git
snapshot.
Err.
It
wouldn't
be
very
good
for
production,
but
it
would
be
kind
of
a
fun
thing
and
I
think
that
would
be.
A
You
know
right
in
the
right
up
the
alley
of
snapshot
so
currently
in
container
D.
We
have
five
implementation.
This
we
have
butter,
FS,
overlay,
ZFS,
a
OFS,
and
what
we
call
native
native
native
is
just
where
you
take
tar
files
and
apply
them
and
then
copy
the
whole
directory
over
and
it's
it.
You
know
it
gives
you
POSIX
performance
at
the
cost
of
remember
the
diagram.
A
I
showed
you
at
the
start,
where
every
container
has
its
own
store,
like
that's
the
kind
of
oh
of
one
worst
case,
but
some
people
need
that
for
certain
things
like
where
you
can't
perform
mounts
on
the
file
system
is
a
great
example.
There's
also,
we
have
a
full
test
suite
so
like
so
graph
drivers
and
docker
like
they're
tested,
but
like
they're,
not
unit,
there's
not
like
a
unit
or
functional
test.
A
You
can't
just
like
modify
the
graph
drivers
and
then
run
a
couple
of
tests
and
know
everything
working
you
have
to
like
test
them
in
the
integration
suite
and
I.
Don't
think
there's
actually
a
full
battery
of
tests,
they're
just
gonna
get
tested
through
the
CLI,
so
you
can't
just
run
the
section
of
tests
with
the
snapchatters.
We
built
a
full
like
fully
verifiable
and
not
fully
that's
the
wrong.
A
Word
I,
like
a
full
integration
test,
suite
that
you
can
just
run
against
your
snapshot,
or
so
you
can
implement
your
fubar
snapshot,
ER
and
then
you'll
know.
If
it's
working
or
not
and
we've
we
test
all
sorts
of
great
edge
cases
in
there
to
make
sure
that
your
snapshot
or
fall
is
the
model
so
going
further
again
container
D
project
experiment
file
bugs
talk
to
us
yell
at
us,
whatever
you
want.
A
Do
it
nicely,
though,
and
the
like
I
said:
the
this
link
is
a
little
messed
up,
but
I'm
sure
you
can
figure
it
out
by
typing
it
in,
but
it's
the
go
doc
to
the
snapshots
package
and
the
snapshot
err
and
it
defines
in
detail
all
of
the
pieces
of
how
these
operations
work,
how
they
should
perform
and
any
kind
of
issues
with
those.
If
you're
more
curious
about
container
D
come
to
my
talk
on
Friday-
and
you
know
it-
you
know,
come
and
ask
about
it.
A
All
I
do
talk
about
snapshot,
errs
there
I'm
gonna,
for
that.
For
this
talk,
I'm
gonna
almost
do
full
demo
mode,
and
we
can
just
you
know
you
can
ask
questions
about
how
things
work
and
I
can
play
around
and
show
different
things.
I
can
show
how
the
snapshot
has
worked
with
other
stuff
too.
So
yes,
with
that
I
think
I've,
five
minutes
yeah.
A
A
B
Hi
I'm
photo
and
I
still
don't
get
it.
So
you
use
overlay
and
with
overlays,
you've
got
a
lot
of
mounts,
and
now
you
just
jump
over
it
and
take
all
the
dips
and
take
another
snap
shot
overlays
in
effort
and
put
everything
in
a
test
that
you
only
have
only
have
one
mount
or
what's
the
big
difference
between
the
old
stuff
in
doctor
using
overlay
to
is.
A
A
They're
pretty
similar
and
docker
usually
only
does
a
single
mount
for
each
layer,
and
it's
defined
like
in
that
mount
command.
The
the
main
difference
is
just
the
fact
that
I
don't
have
to
run
a
container
to
get
this
mount
and
I
can
do
this.
I
can
I
can
pull
this
mount
directly
out
of
the
container
deal
with
a
command
line
tool.
That's
like
the
big,
the
big
difference
and
I
can
safely
a
mount
and
unmount
that
and
and
and
work
and
integrate
with
other
systems.
In
that
way,.