►
From YouTube: Channel Programs by Sara Hartse & Chris Williamson
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
B
C
B
So
we're
just
going
to
give
you
an
update
as
to
where
the
project
is.
It
is
happening.
Yes,
all
right,
also
yell
at
me.
If
you
can't
hear
me
so
first
I'm
going
to
give
some
motivation
for
those
of
you
who
are
unfamiliar
or
don't
remember
as
to
what
channel
programs
are
and
why
we
want
them.
So
the
basic
premise
is
that
there
are
many
gfs
administrative
tasks
that
people
who
run
ZFS
have
to
do
frequently
a
prime
example.
B
B
So
we
have
many
I
octaves
of
this
kind
for
creating
things
making
snapshots
getting
proper
to
you,
setting
properties
all
that
kind
of
stuff,
so
we're
things
hard
to
get
more
complicated
is
when
you
want
to
do
slight
variations
on
these
operations,
for
example,
if
you
want
to
delete
all
the
snapshots
of
a
files
file
set,
so
today
how
that
works?
Is
you
basically
you'd
write
a
script
that
would
call
something
to
give
all
the
snapshots?
You'd
have
a
list
of
them
and
then
for
each
of
those
snapshots
you
would
call
your
delete
I
octal.
B
So
this
is
slow
and
it
has
consistency
issues
so
it's
low
because
you
have
to
go
from
open
to
closed
context
for
each
deletion
and
it
has
consistency
problems,
because,
when
you're
going
from
open
to
singing
context,
you
have
the
possibility
that
things
will
change
your
list
of
all
the
snapshots
may
be
inconsistent.
You
may
try
to
maybe
some
other
process
to
leave
that
snapshot.
Maybe
now
there
are
more
snapshots
than
when
you
started
doing
this.
B
So
basically
you
don't
have
guarantees
that,
like
the
state
of
like
the
world
when
you
started
trying
to
do
this,
deletion
operation
is
going
to
remain
the
same.
So
basically,
the
question
is
how
how
do
we
solve
this
problem?
One
possible
solution,
which
is
kind
of
the
path
that
a
lot
of
these
things
were
going
down
was
okay,
well,
we'll
just
make
a
new
I
octal
octal
will
be
delete
all
the
snapshots
and
it
will
just
go
in
sync
contacts
and
I'll.
B
Do
it
all
it'll
be
consistent
and
it'll
be
great,
but
that
kind
of
raises
the
issue
of
okay.
It's
not
entirely
clear
what
the
semantics
of
that
system
call
would
look
like.
How
would
it
react?
For
example,
if
like
it
failed
to
delete
a
snapshot,
should
it
keep
going?
Should
it
stop
things
like
that?
So
it's
it's
unclear
exactly.
If
you
make
a
new
I
octal
like
this,
what
should
it
do
so?
The
solution
that
was
developed
for
this
purpose
is
channel
programs.
B
B
Basically,
people
have
been
working
on
this
for
a
while
and
we
have
quite
a
few
features
implemented.
So
we
have
these
iterators
developed,
like
I,
was
saying
you
can
list
the
snapshots.
You
can
list
the
children
of
a
file
system.
I
think
you
can
list
clones
things
like
that.
We
have
deletion,
supported,
getting
properties
from
a
data
set
listing
all
the
properties
applicable
for
a
file
set
and
then
recently
the
ability
to
promote
pro
clones
into
into
data
sets
yeah.
So
I'll
just
give
a
quick
example
of
basically
what
it
took
to
implement.
B
B
They
all
have
some
subset
of
about
60,
different
properties
that
have
to
do
with
creation,
time
and
available
space
and
how
many
clones
they
have
and
what
kind
of
like
compression
features
are
turned
on.
Basically,
anything
you
can
think
of,
and
so
this
ended
up
being.
Okay,
where
are
all
these
properties?
They
all
exist
somewhere
in
the
colonel.
B
We
know
we
can
get
them
and
can
we
find
them
and
should
they
be
available
from
sinking
context,
so
there's
pair
mod
inconsistencies
where
to
where
these
are
stored,
some
of
them
are
computed
kind
of
on
the
fly.
One
example
is
a
particular
property
that
this
is
basically
like:
the
user
used
property
which
requires
being
given
a
user
name,
and
then
it
resolves
it
by
contacting
contacting
an
ldap
server
and
we
thought
we
probably
shouldn't
try
and
talk
to
an
ldap
server
while
syncing.
B
So
we
didn't
do
that
and
just
required
that
a
numeric
ID
be
submitted
and
there's
more
work
to
be
done
for
this.
Basically,
questions
like
because
these
were
reading.
These
properties
are
some
DFS
properties
that
are
read-only.
Perhaps
there
are
some
that
we
could
access
without
forcing
a
stink
which
would
make
them
even
faster,
so
yeah
it.
It
was
really
interesting
to
kind
of
see
the
taxonomy
of
ZFS
properties
they're
like
distributed
everywhere,
and
now
we
have
basically
the
ability
to
get
a
consistent
view
of
the
ZFS
metadata
state.
B
Combined
with
this
other
list
system
properties,
you
can
basically
iterate
over
the
system.
Properties
call
get
prop
on
each
of
those
properties
and
then
have
a
view
of
like
okay.
This
is
what
this
is.
What
the
world
looks
like
I
know
it's
what
it
looks
like
because
it
was
done
over
one
sink.
The
state
is
consistent,
it's
great
so
now
Chris
will
talk
a
little
bit
about
current
status
and
future
work.
Cool.
C
The
interface
for
this
is
reached
a
fairly
consistent
state.
We
can
pretty
well
depend
on
like
what
the
output
from
a
channel
program
is
going
to
look
like
and
how
to
control
it
without
worrying.
Like
okay.
Is
this,
like
library
collar
feature
or
something
going
to
change
at
some
point
in
the
future?
C
C
C
This
code
is
sizable
but
fairly
well,
compartmentalize
from
the
rest
of
ZFS,
in
that
we've
added
the
slew
interpreter
and
a
fair
bit
of
infrastructure
to
deal
with
it.
But
modifications
to
existing
ZFS
code
is
fairly
minimal.
We
have
like
some
refactoring
of
some
data
set
layer
code
that
had
to
be
done,
but
for
the
most
part
the
only
significant
changes
are
one
or
two
places
where
we've
experimented
with
using
channel
programs
to
actually
re-implement
existing
aisles.
C
So,
for
example,
the
destroy
snaps
I
octal
now
uses
a
channel
program
to
vastly
simplify
a
lot
of
the
sort
of
iteration
and
error
handling
that
it
needs
to
do
and
yeah
so
I'll
be
available
during
the
hackathon.
If
anybody
is
interested
in
looking
at
this
code
and
yeah,
this
is
sort
of
open
two
editions.
A
B
So
they're
definitely
certain
safeguards
put
on
like
you
can
provide
like
a
time
limit
of
how
long
this
is
allowed
to
execute.
Before
you
just
say,
it's
bad
we're
going
to
stop
now
and
then
also
for
each
of
these
things
that
we're
implementing
we
try
and
put
in
like
a
certain
amount
of
thought
of
like
is
this
something
you
should
be
allowed
to
do,
and
also
can
you
verify
the
behavior
of
what
you're
going
to
do
so
for
most
of
these
like
same
tax
tasks,
there's
a
corresponding
check.