►
From YouTube: March 26, 2019 OpenZFS Leadership Meeting
Description
We discussed log spacemap review; DRAID summit; default pool features; and filesystem GUIDs.
Agenda and meeting notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit#
A
All
right,
it's
one
minute
after
the
hour,
I
guess
that's
the
normal
time
that
we
get
started
so
welcome
everyone
to
the
March
2019
edition
of
the
open,
ZFS
leadership.
Meeting.
I
would
say
we
have
a
pretty
light
agenda
this
week.
So
maybe
we'll
have
this
for
meeting,
but
in
my
experience
every
Jew,
why
we
just
say
read
it's
like
you're
gonna
run
over,
so
we're
probably
gonna
have
a
long
meeting.
Anyways
I.
A
B
C
B
Will
have
all
the
performance
results
with
some
moralism
of
when
we
see
any
rumors
around
like
40%
improvements
in
random,
writes
for
very
fragmented
polls
and
also
for
people
who
are
interested
in
porting.
This
work
I
know
some
folks
from
alone
from
you,
Lumos
have
already
started
this
I've
made
the
list
of
all
the
background
commits
that
I
needed
to
portage
feature
so
yeah
I
just
wanted
to
give
a
heads
up,
I'm,
probably
going
to
send
an
email
to
the
list
to
do
not
find
more
people
but
yeah.
That's
pretty
much
it
cool
thanks.
D
We're
to
have
it
I'm
thinking,
probably
the
Bay
Area's,
the
most
most
convenient
I've
got
an
office
area
in
San
Jose
that
may
not
be
so
convenient,
San
Francisco
might
be
better.
We
did
somebody
to
host
a
conference.
Room
that'd
be
great,
but
the
key
thing
is,
you
know:
who's
who's
really
interested
in
that
particular
project
and
we're
willing
to
be
spend
a
day
on
hashing
through
it.
So
damn.
A
G
A
D
D
A
So
now
I
think
we'll
move
on
to
one
of
the
meteor
topics
for
today,
which
is
the
default
full
features.
So
thanks
a
lot
Josh
for
looping
that
discussion
and
putting
together
the
proposal
that
was
sent
out
to
the
mailing
list
yesterday,
there's
some
good
discussion
following
that.
So
I
guess:
why?
Don't
we
Josh?
Why
don't
you
do
you
want
to
kind
of
summarize
the
proposal
and
then
gather
any
more
comments
or
discussion
here.
A
A
Basically
it
it
works
on
all
tier
1
platforms,
current
versions,
so
that
definition
would
actually
change
over
time.
As,
like
you
know,
features
were
made
available
on
more
platforms,
tier
1
platforms.
The
proposal
is
that
that
would
be
a
member
to
release
the
FreeBSD.
You
know
a
previous
key
11.1
or
whatever
I,
never
release
of
ZFS
on
Linux.
So,
like
you
know,
zo
l,
o
dot,
7.14
and
illumise
doesn't
have
releases,
so
it
would
be
the
code
in
Lumos
gate
as
a
one
year
prior.
A
A
That
was
the
that's
the
main
just
a
bit
on
the
additionally,
we
would
remember
on
disk-like
which
a
portable
thing
you
specified
last
so
if
you
created
the
pool
with
deco
features,
equals
portable
mm
whatever.
Then,
since
that
definition
never
changes
when
you
run
the
gazebo
status
or
is
equal
upgrade,
it
would
assume
that
you
have
stick
with
whatever
portability
definition
you
gave
originally,
so
it
wouldn't
prompt
you
to
upgrade.
A
If
you
do
that,
when
that
definition
of
word
will
changes,
so,
in
other
words,
you
have
to
like
upgrade
to
a
newer
version
of
the
software
which
has
a
newer
definition
of
the
portable,
which
says
that,
ok,
now,
as
of
the
time
that
the
software
year
running,
was
released,
all
of
the
tier
1
platforms
supported
disk
feature
and
yeah,
so
that
would
be
remembered
on
disk
so
that
we
could
make
those
changes
to
the
ways
equal
status.
Nz
will
upgrade
work.
A
So
that
was
the
main
part
of
the
proposal.
I'll
summarize
the
discussion
or
the
the
questions
that
were
raised
on
the
mailing
list.
Since
yesterday
there
was
a
request
to
be
able
to
basically
define
the
feature.
The
feature
sets
at
runtime
like
in
a
configuration
file,
so
you
can
add
new
definitions
on
your
own
and
there
was
some
discussion
around
that
and
let
me
I
thought.
Oh,
there
was
one
more
oh.
A
There
was
another
discussion
about
the
idea
of
the
cheer
one
platform
being
as
if
s
on
the
next
numbered
release,
as
opposed
to
release
of
a
specific
distro
like
Ubuntu
or
you
know,
whatever
the
issue
being
like.
If,
if
folks
are
running,
you
know
if
they're
running
Ubuntu
and
they
upgraded
they're
a
bunch,
you
then
they
they
might
necessarily,
they
may
not
necessarily
care
about
like
yeah.
It's
great
that
gol
supports
this,
but
like
about
who
doesn't
and
I'm
using
to
a
bunch
of
these
I
think
those
are
the
only
two.
A
Oh
there
was
also
a
there's,
also
an
issue
raised
about
root,
pools
and
the
fact
that
grub
doesn't
necessarily
support
all
the
features
that
any
of
these
two
on
platforms
do
and
so
I
guess.
That's
kind
of
a
summary:
the
issues
that
were
raised
all
I
give
quickly
my
take
and
then
we'll
open
it
to
discussion.
So,
in
my
opinion,
the
additionally
having
a
list
of
having
like
user
configurable
lists
of
features
might
or
might
not
be
useful.
I
think
that
it's
not
something
that
we
need
to
include
in
the
core
requirements.
A
A
I
think
I
would
probably
ask
like
which,
which
distros
are
shipping
their
own
diversions
and
kind
of
how
important
are
they
and
on
the
last
issue
of
grab
I
think
that
we
had
previously
discussed
rules
like
in
a
you
know
on
the
mailing
list
during
this
meeting
a
couple
months
ago
and
basically
decided
that
that
was
like
too,
and
we
were
going
to
defer
that
to
future.
You
know
your
post
post
initial
implementation
for
handling
route
pools
and
in
grow
so
open
up
for
discussion.
I
see,
Shawn
has
a
few
comments
posted
and
he
already.
H
Good
as
a
comment
in
the
chat
mess,
is
there
I,
don't
think
having
that
it
or
file?
Is
all
that
good,
an
idea
too
easy
to
shoot
yourself
or
make
things
that
aren't
actually
portable
and
the
only
other
thing
I'm
looking
over
the
dis,
Justin
Josh
is
a
proposal.
The
only
thing
that
I
can
think
might
be
useful
and
I,
don't
know
if
it
would
be
in
reality
is
wearing
a
pool
against
compatibility
list.
This
result
would
also
be
useful
for
the
boot
pool
case,
namely
you'll.
Be
able
to
see.
A
You
specifically
I
think
that
part
of
the
proposal
was
for
there
to
be,
like
essentially
cool
property.
That
would
tell
you
what
you
have
said
like
oh
I
went
to
be
affordable
as
of
2018
or
whatever,
but
are
you
guys
seeing?
Are
you
seeing
specifically
like
with
one
of
those
to
your
one
platforms
like?
Does
this
to
your
one
platform,
support
this
feature?
Well,
I.
H
G
A
F
G
Also
think
I
think
the
thing
that
we
probably
should
resolve
at
like
a
design
goal
level
is
why
we're
doing
this
and
because
I
think
that
effects
like
a
lot
of
the
questions.
People
asking
about
like
how
aggressive
should
be
moved,
the
targets
forward
and
I
think
the
core
of
the
goal
seems
to
be
to
err
on
the
side
of
portability
rather
than
currency,
on
some
level,
at
least
right,
at
least
where
a
decision
has
to,
because
that
the
kind
of
effects
like
if
there
is
a
popular
Linux
distribution,
that's
lagging
behind.
G
A
Know
well,
I
think
it's
probably
doable
I
mean
I
I.
Think
that's.
That's
certainly
like
I
think
it's
a
valid
point
of
view.
I
think
personally,
I
think
he
a
bit
more.
As
from
the
point
of
view
of
most
people
aren't
moving
their
rules
between
systems,
but
they
want
to
maintain
the
option
of
being
able
to
do
that
and
and
and
so
I
I
was
kind
of
coming
at
it
from
a
more
permissive
point
of
view
of
having
the
more
current.
A
So,
for
example,
including
you
know,
the
0l
releases
rather
than
the
specificity
releases,
because
you
know
if
you,
if
you
want
to
open
your
pool
on
your
Red
Hat
system.
Well,
even
if
like
even
if
the
room
there
it
has
shifting,
doesn't
support
it.
You
can
still
install
the
ZL.
You
know
our
cams
from
the
co-op
site.
G
A
F
Let
me
take
a
stab
at
that,
so
the
answer
is
they
ship
all
of
the
versions?
I
would
say
so
they're
a
great
many
different
converts.
This
guy's
and
they're
gonna
make
their
own
decisions
about
what
to
ship
right.
We
have
a
stable
release,
vo7
stuff,
that
we
encourage
them
to
ship,
but
versions
like
arch
linux,
ship,
something
much
newer,
mbutu's
ships
vo7,
which
we
encourage
and
then
there's
releases
like
rel,
which,
if
they
package
something
up
and
ship
with
it,
you
know
they
might
want
it
to
be
unchanged
for
five
or
seven
years
right.
F
F
I
F
A
So
you
know
yeah
rel
would
not
be
in
on
this,
but
it
sounds
like
you
know,
a
bunch
you,
arch
and
Debian
would
be
since
they
shift
their
own
versions
of
the
on
Debian.
Something
Debian
is
essentially
the
old
it.
What
sheeting
the
oldest
is
that
on
current,
like
on
current,
whatever
the
current
version
of
Debian
is,
they
are
shipping
at
six,
no.
F
A
So
my
before,
like
on
the
it,
was
for
the
most
recent
version
so,
like
you
know,
for
it
to
take
FreeBSD
as
an
example,
you
know,
I
was
proposing
that,
like
there
is
some
support,
there
is
a
supported
version
of
FreeBSD
which
supports
these
features.
Therefore
it
is
portable
to
FreeBSD,
not
not
that,
like
all
supported
versions
of
previously
I
have
to
support
it.
If
that
makes
sense.
So
you
know
in
the
case
of
assuming
we
can
assume
folks
agree
with
that.
F
Yeah
I
mean
that
makes
sense.
They're
all
gonna
have
their
own
update
cycles
to
when
they
pick
up
the
latest
thing,
but
does
that's
just
up
to
them?
I
guess
it's
good.
The
case
in
point
might
be
boot
to
1804,
which
is
their
current
LTS,
which
is
shipping
though
7
release,
and
they
will
continue.
They
will
not
update
that.
As
my
understanding
until
you
know,
they're
done
with
it
so
2023
sometime,
you.
A
J
A
So,
given
that
I
mean
given
that
kind
of
about
to
else,
yes
is
what
folks
care
about,
and
it
only
comes
out
with
the
release:
every
is
it
two
years
yeah
they're
right,
you
know,
would
we
I
mean
if
we
made
a
bunch
of
else?
Yes,
a
Tier
one
platform,
then
that
that
would
you
know
that
would
be
a
significant
portability
hit
or
you
know,
Pete
features.
A
lot
of
features
would
be
disabled
for
a
long
time,
because
that
it,
how
do
you
folks
feel
about
that
trade-off?
I
think.
G
Because
we're
not
making
portable
the
default
I
think
that's
like
I
think
if
you
want
portability,
I
think
that
is
I.
Think
the
the
thing
we're
talking
about
reflects
the
very
real
trade-off
right
like
to
actually
get
portability.
You
need
to
not
enable
new
features,
possibly
for
a
couple
of
years.
Yeah.
A
G
I
think
you
know
for
people
that
don't
need
it,
they
should
know
the
neighborhood
probably,
and
then
they
should
just
get
the
things
as
they
come
out.
I
think
makes
I,
don't
know,
I
think
it's
kind
of
of
a
constraint
right.
You
can't
really
have
it
both
ways,
particularly
with
like
two,
you
release
cycles
for
LTS
platforms,
yeah.
A
I
think
that
the
fundamental
tension
is
kind
of
between
the
the
view
that
you
outlined
in
the
one
that
I
did
in
terms
of,
like
the
point
of
view
of
like
I,
might
want
to
build,
to
bring
this
pool
to
another
operating
system
and
like
I,
want
to
bring
it
to
another
operating
system.
That
is,
you
know,
look
like
the
production
line
right
like
right.
A
Well,
for
that,
like
I,
want
to
it
like,
of
course,
you'd
be
a
bunch
of
LTS
cuz
like
that's
the
one
that
you
know,
everybody
uses
in
production
as
opposed
to
kind
of
the
view
that
I
was
pointing
out
which
is
like
so
I
have
my
pool
on
a
Lumos
I
want
to
be
able
to
get
to
like
Linux,
somehow
and
so
like
as
long
as
there's
some
version
of
Linux.
That
has
it
then
that
I'm,
okay,
for
you.
G
A
A
I
kind
of
summarized
that
proposal
and
items
that
were
discussed
on
the
mailing
list
and
right
now
we're
talking
about
kind
of
what
what
should
be
R.
What
should
be
a
tier
one
platform,
and
why-
and
the
discussion
is
kind
of
around
is-
is
the
goal
like
that,
any
you
should
there
should
be
some
version
of
Linux,
slash,
FreeBSD,
slash
illumise,
that
you
can
bring
your
blue
to
or
or
is
it
really
centered
around
like,
like
the
the
main
production
version,
main
production,
you
know
distro
on
supports,
it
supports
the
features
that.
H
K
K
You
know
I
mean
I,
think
the
reality
is
we
can
you
know
when
you
talk
about
Linux
distros,
that
people
use.
You
can
usually
collapse
that
list
down
into
a
these
are
well
supported.
Linux,
distros,
you
know,
you
know,
/rel
sent
us
a
bun
LTS,
you
know
you,
you
could
argue
a
debian
release
and
and
I
really
think
the
portable
feature
should
should
be
tied
to
Linux
releases
distro
releases
that
are
significant.
K
K
A
You
know
I'm
hearing
some
arguments
for
the
more
conservative
view
that,
basically,
that
a
bunch
of
LTS
should
be
a
tier
one
platform
and-
and
you
know
that's
fine-
we'll
deal
with
the
fact
that
logic
will
be
enabled
I
mean
my
my
as
I
said.
My
opinion
is
not
strongly
held
so
II.
You
know
if,
if
somebody
doesn't
want
to
argue
strongly
for
the
against
that,
against
the
having
my
do
LTS
as
a
tier
one,
then
I
think
we
should
probably
move
forward
with
that.
I.
F
A
So
so,
let's
go
ahead
and
say
that
a
bunch
of
LCS
will
be
tier,
1
and
then
I
saw
the
comment
about
you
know
the
current
was
it
that
that
Steve
pointed
out.
You
know
the
current.
A
bun
LTS
has
no
75,
but
you
know
a
bun
LTS
1604
is
still
supported
by
a
bun
and
they're
using
over
that
six
I
I
would
fairly
strongly
argue
that
we
should
go
with
we're.
Only
talking
about
the
current
LTS
and
not
all
supported
LCS
is
because
that's
just
too
far
I
agree.
G
With
that
you
folks
are
okay
with
that,
but
by
the
time
the
new
LTS
comes
out,
you
can
probably
have
changed
your
portable
decision
to
the
previous
year
or
something
I
think
right
as
well.
So
that's
kind
of
that's
within
the
bounds
of
the
proposal
as
it
exists
today.
That's
really
the
only
slaughter
that
you
get
I
think
yeah
picking
a
specific
year
as
a
static
target.
Instead
of
you
know,
instead
of
the
the.
J
L
Know
Richard
lager
is
a
working
with
canonical
for
some
of
those
future
releases
of
Ubuntu
making
that
happen
a
good
reason
for
it
to
be
actually
a
Tier
one
support
of
things
a
little
more
evidence
that
way,
but
yeah
I
don't
have
any
more
information
than
that.
Another
thing
I
just
want
to
mention,
though,
also
is
that
there
are
hwe,
are,
were
update,
kernels
that
go
into
the
LTS,
usually
that
they
start
up
the
the
point
two
and
it
is
possible
for
even
newer
versions
the
zo
l
mod
kernel
module
to
be
in
those
I.
L
K
You
know,
I,
think
that
a
typical
or
a
common
use
case
of
portable
pools
is
I'm
gonna
plug
this
shelf
in
over
here
you
know:
I
used
to
run
FreeBSD
and
now
I'm
gonna,
try
Linux
for
the
shelf
I
feel
like
a
boot
pool
with
an
OS
on.
It
is
less
likely
to
be
portable
to
something
else
like
you're,
not
gonna,
boot,
another
OS,
because
it's
already,
you
know
s
there
and
you
know
if
I
poach
my
freebsd
11
to
desktop
and
want
to
recover
stuff
off
of
the
ZFS
pool.
G
F
A
A
Yeah
I
think
internal
representation
like
I
would
be
fine
with
leaving
that
to
whoever
decides
to
implement
it
like
if
they
want.
If
they
want
input,
that's
fine,
if
not,
they
can
implement
it,
and
then
we
can
hash
it
out
in
code
review.
I.
Think
having
this
like
having
the
kind
of
specification
of
what
is
supposed
to
do
is
super
helpful
in
terms
of
guiding
the
implementation
and
making
sure
that
we
don't
implement
stuff.
That
turns
out
to
not
be
what
folks
want.
A
J
So
in
the
course
of
this
I
discovered
that
there
is
actually
the
GID
property
which
I
put
a
PR
up
to
make
public,
and
it
is
now
public
and
I
think
quite
widely
supported
and
I
already
use
it
to
basically
figure
out
the
disk
between
two
different
file
systems,
because
G
IDs
are
invariant
across
replication.
So
when
the
snapshot
is
replicated,
it
has
the
same
GID
on
the
target
system.
J
The
problem
is
that
this
does
not
apply
for
the
file
system
itself,
so,
like
zeroed
user
home
will
have
a
different
GID
on
the
receiving
by
receiving
pool,
even
though
it
is
the
same
thing
like
it
was
received
with
the
CSS
receive
command,
and
this
is
a
problem
because,
when
users
start
to
rename
file
systems
on
the
source
side,
I
want
to
be
able
to
like
still
figure
out
the
which
file
system
on
the
receiving
side.
It
is
so
I
need
some
kind
of
identifier
for
that
right
now,
I,
just
don't
do
it.
J
I
rely
on
the
file
system
name,
but
that
is
kind
of
terrible
thing
to
do
and
I'm
looking
for
ideas,
and
so
my
idea
was
basically
to
assign
a
goig
to
the
I
on
the
sending
side
and
then
replicate
that
geo
ID
through
in
like
a
property
or
out
of
Benton
and
or
something
to
the
receiving
side
and
started
there
and
use
that
to
figure
out
the
divs
and
I
was
thinking.
This
is
not
just
useful
for
my
case
and
but
maybe
also
for
others
and
yeah
ideas
or
opinions.
G
J
A
Yes,
more
well
than
I
would
like
yeah.
So
the
way
that
that
works.
It
is
all
in
user
land
but
the,
but
it
does
work
in
the
way
that
it
works
is
so
you
have
the
when
you
do
the
send.
You
have
the
from
do
it.
So
you
know
like
I'm,
sending
this
this
this
stream,
and
it's
from
this
good
to
this
new,
good
and
you're.
Right
that
you
don't
know
you
don't.
There
isn't
necessarily
easy
way
to
know
the
name
of
the
file
system
on
the
target
if
there
have
been
renamed.
A
But
if
you
like
exhaustively
search,
you
can
find
which
snapshot
has
that
same
gooood
as
the
from
good.
So
basically
you're,
like
looking
at
all
of
the
file
systems
and
you're
kind
of
hoping
to
find
one
whose
most
recent
snapshot
is
the
one
with
the
same
gooood
as
the
from
good
that
the
individual
sent
stream
is
describing.
A
There
are
a
weird
kid
like
you
can
receive
the
same
file
system,
the
same
snap
shot
multiple
times
in
one
pool,
in
which
case
like
you
can
have
two
that
have
the
same
I.
Imagine
you'd
have
that
same
problem
with
kind
of
what
Chris
is
proposing,
like
you
know,
when
you
do.
If
we
had
this
like
BS
elder
or
gooood,
then
like
when
you
receive
it,
you
would
set
it
to
be
the
same
as
it
is
on
the
source.
A
J
I
think
it
would
work
I.
Think
the
the
exhaustive
search
is
a
nice
trick,
but
I
think
it
is
ambiguous
with
regards
to
identifying
the
the
root
source
of
the
conflict.
So
I
think
if
you
do
the
exhaustive
search
approach,
you
cannot
distinguish
whether
things
have
fully
diverged
like
whether
there
has
been
an
initial
replication
and
then
things
diverged,
because
people
deleted
snapshots
randomly,
and
so
there
is
no
longer
a
common
ancestor
or
something
we
could
use
to
replicate
versus.
There
has
never
been
a
replication,
so.
A
Your
mother
case,
where,
like
you're
doing
it
you're
doing
with
with
the
sin
capital
R,
if
you
don't
have
the
target
it's
like.
If
you
did
this,
if
you
did
their
application
once
and
then
you
deleted
the
snapshots
and
then
you
do
their
incremental
replication.
It's
just
going
to
say
like
hey
like
you,
don't
have
that
file
system
anymore,
because
you
deleted
one
of
the
snapshots.
You
deleted
the
critical
snapshot
and
so
too
bad,
but
I
think
you
are
asking
about
like
I.
A
Think
your
replication
thing
it
has
like
bi-directional
communication
so,
presumably
like
you
could
figure
out
like.
Oh
this
file
system
is
actually
the
same
as
that
one,
and
we
have
this
little
snapshot
in
common,
so
I'm
gonna,
like
incremental
from
there
or
even
like
we
have
no
snapshots
in
common,
but
it's
the
same
file
system
and
so
like
I'm,
gonna,
I,
don't
know
delete
that
one
locally
and
then
we
replicate
everything
is
a
sir.
What
you
thinking,
question
yeah.
J
G
A
A
J
Okay,
I
think
the
like
we
met
is
it.
Is
it
guaranteed
that
there
are
no
collisions
of
jihadis
within
a
data
set
like
for
the
different
snapshots
of
the
data
set
I
think
it
ZFS
should
assert
that
the
Geo
IDs
to
not
collide
doesn't
I,
don't
know
that
we
make
that
assertion,
but
I
believe
that
is
correct.
It.
J
J
A
Yeah
I
mean
I
was
to
kind
of
address.
We've
been
talking
about
kind
of
how
to
solve
the
problem
in
general.
I
think
that
the
kind
of
the
given
property
that
you're
proposing
for
that
would
kind
of
be
sticky
with
the
data
the
DSL
during
I
mean
I.
Think
that
would
be
fine,
like
I.
Don't
have
any
problem
with
implementing
that
or
with
with
somebody
implementing
that,
and
it
seems
like
it
might
be
useful
in
these
cases,
I
think
you
can
probably
get
most
of
what
you
want
from
the
existing
data
set.
A
A
We
would
I
mean
since
nothing
today
nothing
relies
on
this
good
that
so
I.
Obviously
we
could
change
it.
We
could
write
some
code
that
changed
is
it,
but
we
would
probably
want
to
think
hard
about
like
what
guarantees
we're
trying
to
make
with
big
youíd,
and
if
it
would
be
helpful
to
allow
that
to
change
or
not
I
like
I
would
imagine
it
would
probably
be
like
fine
I
mean
it
like
it
might
be
like.
Oh,
if
you
do,
then
you
know
your
application
might
get
confused
or
whatever,
but
I.
J
A
C
I
C
C
So
basically,
what
I
would
like
to
do
is
if
I
recover
my
pool,
for
example,
my
/tmp
file
sister
is
there,
but
it's
just
empty
and
all
the
properties
if
I
have
compression
turned
on
and
stuff
like
that,
it's
older,
so
I
don't
have
to
create
a
file
system.
So
I
would
like
to
replicate
like
empty
file
system.
Just
not
the
content
were,
but
that's
option.
That's
an
option,
let's
say,
but.
A
I
mean
I'm
sure
that
you
could
hack
that
up
and
I
think
that
kind
of
the
ignoring
the
part
of
like
sending
the
metadata,
but
not
the
data,
I
think
I'm.
Pretty
sure
that
that
was
implemented
by
somebody
somewhere
I
think
we
might
have
done
that
like
at
Sun
for
fishhooks,
for
some
reason
where
you
could
like
exclude
pruning
a
trait
from
the
package.
C
Actually,
there
is
actually
a
hack
I
was
able
to
come
up
with.
Maybe
it
will
be
useful
for
somebody,
but
if
you
snapshot
an
empty
file
system
or
create
two
snapshots
on
empty
file
system
and
then
just
rename
those
snapshots
you
can
actually
every
it's
I
was
surprised
that
it
actually
works,
but
but
it
does
so
yeah.
A
I
mean
I
would
be
open
to
you
know
somebody
adding
that
functionality
either
they're
like
exclude,
exclude
these
sub
file
systems
entirely
or
maybe
exclude
their
datum
and
other
metadata
and
then
have
the
target,
like
I
assume.
The
reason
that
you
want
to
include
the
mend
it
is
so
that
when
you
do
the
receive
the
the
receive
want
to
like
change
the
properties
on
the
target
to
reflect
what
they
are
on
the
source,
yeah.
C
G
H
A
Yeah,
can
you
use
redact
instead
to
receive
for
this?
Actually,
that's
a
great
point.
I
bet
that
you
could
get
exactly
what
you
want
with
a
debt
with
reduction
center
receives
you
just
protect
the
contents
of
that
file
system.
Right
yeah,
but
you
just
create
a
clone.
Rm
are
everything
in
the
clone
and
then
say
like
I,
want
it
redacted
with
respect
to
the
empty
clone
and
then
the
target,
like
you,
won't,
send
any
data
you
have
that
file
system.
A
So,
as
predicted,
we
we've
come
to
the
end
of
the
meeting
time.
We
still
have
one
it
one
agenda
item
so
which
is
the
enable
compression
by
default.
I.
Think
that's
probably
a
more
than
six
minute
discussion.
So
let's
move
that
to
next
next
meeting,
any
any
final
thoughts
or
comments
for
today.
Oh
how
about
how
a
meeting
time
I
think
that
we
we
had
talked
about
doing
like
two
at
this
time
and
then
one
at
the
earlier
time
kind
of
actually
I
don't
of
three
yeah.