►
From YouTube: February 26, 2019 OpenZFS Leadership Meeting
Description
We discussed Fast Clone Deletion; FIPS 140-2; making compressed ARC mandatory; and platform-specific 'sharenfs' property.
Agenda and meeting notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit
A
A
A
D
C
Yeah
in
general,
we're
trying
to
kind
of
figure
out
like
how
much
review
does
this
need,
who
wants
to
weigh
in
on
it?
We've
been
running
it,
it's
all
fixed
for
10
months
or
so,
and
there
are
a
ton
of
code
changes
platforms
and
between
what
we
have
running
internally.
So
it's
not
like
the
kind
of
changes
from
like
what
we
believe
to
work,
but
it's
still
like
I
think
people
just
look
at
it
I'm
happy
to
answer
more
questions
about
it.
C
A
If
not,
then
I'd
be
interested
to
hear
from
from
Ryan
as
to
what
review
you
would
like
to
see
for
as
if
it's
on
Linux,
specifically
given
we've
already
had
a
bunch
of
a
bunch
of
people,
have
reviewed
it
when
it
went
to
del
phix
and
I.
Think
all
those
reviews
you
know
apply
certainly
apply
to
the
illumos
version
as
well:
Neela's
PRS,
since
the
changes
there
were
pretty
negligible
right
and
the
changes
to
the
Linux
one
I
think
did
my
apply
there
as
well.
We
might
want
to
have
someone
else.
A
Just
check
over
you
know,
do
a
quick
look
at
it,
but
I
think
we
have
quite
a
you
know
quite
a
few
folks
that
reviewed
it
internally
with
with
minimal
changes,
so
any
volunteers
all
right
feel
free
to
get
in
touch
with
us
after
Brian.
Do
you
have
any
thoughts
on
what
you'd
like
to
see
why
digital
review
you'd
like
to
see.
F
B
A
G
So
I
work
for
a
defense
contractor
and
fairly
new
to
me
that
business
but
I've
been
using
ZFS
for
a
while
and
I'm
seeing
a
lot
of
places
where
it
could
be
applied
in
the
defense
industry,
and
one
of
the
requirements
for
doing
so
is
what
they
call
Phipps,
which
is
federal
information
processing
standard.
And
it's
it's
a
way
to
get
encryption
certified
for
use
for
stuff
related
to
the
US
government
and
I.
Don't
know
the
full
process
for
that.
But
I
know
that
other
stuff,
like
diem
crypt,
has
already
gone
through
the
process.
G
G
D
H
A
On
the
destroy
think
so,
like
you
know,
bunty
provides
binaries
and
they
are
the
only
major
destroy
that
does
so
so
like
folks,
easy
on
RedHat
are
probably
compiling
it
from
source
as
far
as
I
know,
I
and
other
folks,
outside
of
things
might
not
be
aware,
but
the
the
actual
encryption
implementation
that's
used
by
ZFS
on
Linux
is
the
illumise
one
that
that
was
ported
from
you
know.
The
illumise
kernel
encryption
framework
was
a
kind
of
Linux,
so
I'm
sure
that,
like
at
some
point,
Sun
slash
Oracle,
you
know
got
that
stuff
certified.
A
Release
you
know
that
was
like
the
Solaris
10.7
write.
Binary
was
certified,
so
it
seems
like
you
would
be
tricky
for
the
project
to
do
that
kind
of
certification.
If
it
is
on
a
like
for
binary
or
these
basis,
it
would
make
more
sense,
probably
for
a
distro.
That's
going
to
be
saying.
Like
we're
shipping,
you
know
a
bun
to
version
7
and
like
we,
we
certified
ZF
at
the
ZFS
that
we
ship
the
emoji
version.
7
is
FIPS
140-2.
A
I
A
D
That
actually
might
make
things
a
little
easier.
I
said
some
digging
into
some
of
the
documentation.
I
have
cuz
when
we're
looking
at
some
of
this
kind
of
same
kind
of
stuff
over
over
here
for
entirely
non
ZFS
related
products,
but
source
code.
Validation
is
also
something
that
we
can
do.
It
is
looked
at
during
the
the
validation
process,
so.
J
But
my
understanding
for
open
source
projects,
what
we
can
do
as
a
community
I
guess,
is
to
just
prefer
ZFS
to
be
easy
to
to
be
certified.
So
what
we
can
do,
for
example,
add
a
bunch
of
Eva
deaths
that
basically,
so
you
are
able
to
easily
exclude
encryption
algorithms
that
are,
that
cannot
be
part
of
hips
and
do
stuff
like
that.
So
we
cannot
really.
J
It
doesn't
really
make
sense
to
certify
it
opens
EFS
as
a
project,
but
it
it
would
help
other
vendors
that
build
products
on
top
of
open
ZFS
to
to
have
this
component
to
be
easily
certified,
because
each
vendor
has
to
actually
submit
his
own
product
and
this
product
has
to
be
certified.
So
we
can
just
make
this
process
easier
as.
D
Gonna
be
the
easier.
The
easier
way
to
go
is
sort
is
like
provide
like
an
alternate.
You
know,
build
sorry
altering
the
set
of
build
instructions
that
would
remove
the
stuff
that
that
isn't
compliant.
If
we
wanted
to
start
doing
a
binary
build
for
the
community,
that
was
that
we
could
get
v.
Certified
I
can
definitely
see
what
I
can
do
on
my
end,
help
sponsor
support
that
I'm.
Sure
I've
got
some
room
in
my
butt,
and
my
budget
is
here.
E
As
it's
been
stated
most
times
when
you're
sort
of
getting
a
certification
from
tips,
it's
for
a
specific
release
if
they
are
allowing
software.
That
is
a
change
because
it
used
to
be
allowed
to
be
a
particular
machine
with
a
particular
version
of
the
software
on
a
configure
in
a
particular
way.
I'll
point
out
that
Windows
was
able
to
get
certified
for
being
secure,
but
the
cert
of
the
environment
they
submitted
for
testing
had
and
no
networking.
A
Yeah
so
I
think
probably
we
need
to
do
some
more
research
here
if
we
want
to
pursue
this
one
nice
thing
that
kind
of
relates
to
your
question.
Is
that
the
my
understanding
is
that
the
actual
crypto
the
certification
applies
to
the
like
encryption
products,
which
is
a
separate
kernel,
module
I'm,
not
sure
how
much,
if
at
all,
the
certification
would
really
depend
on
ZFS
per
se.
Oh
yeah
yeah.
A
I've
looked
at
it,
but
maybe
I
didn't
totally
understand
it
all
right.
Well,
it
sounds
like
Luke,
maybe
connect
with
some
of
the
folks
here
that
are
really
much
more
knowledgeable
than
I
am
and
I
think
you
know,
as
a
community,
we're
probably
willing
to
do
to
help
out
and,
like
you
know,
if
there's
like
you
said,
build
options
and
stuff
that
we
can
do
to
make
it
easier
to
death
certification,
that's
cool
I'd!
Only!
It's
probably
not
something
that,
like
the
project,
is
going
to
be
undertaking
from
a
top-down
approach.
I.
Imagine.
I
D
It
should
also
be
noted
that
we
can
do
the
work
to
get
ourselves.
It's
compliant,
there's
no
official
usage
for
that
term,
so
we
could
do
the
work
to
make
it
easier
to
build
like
what
was
suggested
earlier.
You
know
how
to
have
proper
option
option
flags
to
take
out
the
stuff
that
wouldn't
be
compliant,
and
we
could
say
that
you
know
it's
just
compliant,
but
not
that's
just
validated
and
then
let
you
know
people
pull
that
stuff
down
and
do
their
own
builds
and
go
through
the
headache
on
their
own.
You
can
do.
J
F
E
Can
have
more
than
they
allow
it's
just
that
when
you
go
to
configure
in
a
particular
way,
it
has
to
be
fips-compliant
for
the
validation
so
having
extra
cryptographic,
algorithms,
hash,
algorithms,
etc
is
not
a
problem
for
that.
They
just
have
to
be
able
to
s,
be
able
to
select
the
ones
that
are
approved.
G
D
A
So,
let's
circle
back
to
the
reviewers
for
fast
phone
dilution
know
that
we
can
hear
Brian
so
give
Brian
the
question,
for
you
was
what
it,
what
additional
review?
Would
you
like
to
see
before
this
goes
into
Linux?
Given
that
you
know
it's
been
pretty
thoroughly
reviewed,
the
illumise
version
has
been
pretty
thoroughly
reviewed
and
I.
Think
we
could
have
somebody
do
another.
You
know
once-over
of
the
Linux
version,
but
why
additional
would
you
like
to
see?
I
was.
I
Gonna
say
that
this
is
actually
looks
like
it's
really
good
shape
to
me.
It's
been
seen,
I.
Actually
volunteered
myself
to
review
it.
So
I
got
a
chance
to
look
over
it
at
least
a
little
bit
and
yeah
I
didn't
have
any
real
complaints,
so
I
think
be
great.
If
we
could
get
another
reviewer
I,
don't
look
excited
to
look
at
it
and
see,
but
I
mean
it
held
together
through
all
the
automated
testing.
You
guys
have
done
a
ton
of
work
testing
at
adelphic,
so
that
seems
to
be
in
great
shape.
I
I
A
Yeah
but
yeah
depends
on.
We
know
that
it
is
right
like
where
we're
trying
to
get
well.
You
know
we're
trying
to
not
carry
a
ton
of
discs,
so
we'd
like
to
get
it
up
streamed.
You
know
sooner
rather
than
later,
so
that
we
can,
you
know,
have
our
products
tested
on.
You
know
the
with
all
the
features
you
know
sooner
rather
than
later,
but
it's.
I
A
I
But
the
only
thing
blocking
AP
well
circle
back
to
that
a
little
bit
our
trim,
which
also
needs
reviewers
and
there's
a
pull
request
that
went
up
for
that
a
couple
weeks
ago
and
then
some
of
the
sixes
we
talked
about
before
for
encryption
that
still
need
to
go
in
there's
a
pull
request:
I'm
open
for
that
as
well.
A
really
big
thing.
A
F
A
Cool,
so
let's
move
on
to
the
next
agenda
item,
which
was
should
compressed
Ark,
be
mandatory
on
Alan
dude.
You
brought
this
up
on
github
and
thanks
for
leading
that
discussion,
do
you
wanna?
Can
you
I,
guess
first
start
by
summarizing
like
what?
What
would
their
real
it
changed,
be
here
like
what
would
the
impact
be
and
then,
if
you
could
kind
of
summarize,
the
discussion
so
far.
B
It
caused
a
bit
of
complication
with
the
way
the
L
2
are
quirks
really
to
previous
work.
That
George
Wilson
did
so
that
the
checksum
for
the
version
written
to
the
l2
arc
device
is
the
same
as
the
on
disk
version,
whereas
previously
I
think
it
was
always
I
was
led
for
so
it
was
different,
the
intent
that
was
to
avoid
storing
a
different
checksum
as
part
of
the
l2
arc
header
and
said
just
feedback
on
the
checksum
of
the
block
pointer.
B
So
that
means,
if
you
disable
compressed
arc,
the
copy
in
the
arc
no
longer
matches
the
copy.
That's
on
disk
in
the
main
storage.
And
so
when
you
go
to
feed
the
l2
arc,
you
might
have
to
recompress
the
block
or
yes,
if
compressed
arc
is
off,
you
might
have
to
recompress
the
block
before
you
write
it
to
the
l2
arc
to
get
the
same
checksum
when
we're
back
from
the
l2
arc
sometime
in
the
future,
and
this
can
cause
a
problem
if
your
compression
algorithm
doesn't
actually
produce
the
same
result.
B
Every
time
which
can
happen
if
you're
mixing
software
gzip
and
the
quick
assist
off
loaded
gzip,
because
they
use
a
different
reference
table
or
something
or
if,
for
example,
using
Zed
standard
compression
and
you're
using
a
newer
version
of
Zed
standard.
Now,
then,
when
you
originally
wrote
the
blocks
to
disk,
and
so
a
question
became,
does
anybody
ever
turn
the
compress
start
feature
off?
B
And
if,
if
nobody
does,
then
maybe
we
could
avoid
having
to
make
more
special
cases
for
the
l2
arc
in
that
case,
but
some
people
have
made
reasonable
cases
for
why
you
might
want
to.
Although
I
don't
know
that
anybody
has
made
the
case
of
they
actually
do
disabled
to
compress
dark.
There
was
also
today
a
reference
to
another
issue
on
the
edifice
on
Linux
github,
where
apparently,
if
you
poke
some
file
in
slash
sis
to
erase
the
cat
or
dump
the
caches,
it
causes
a
panic.
When
you
try
to
read
from
the
arc.
A
That's
that
was
that
was
how
it
was
originally
filed,
but
then
the
person
to
report
that
updated
to
indicate
that
the
issue
was
actually
when
they
had
turned
off
compressed
Arc.
If
you
used
L
to
work
at
all,
then
systems,
or
so
it
seemed
like
at
least
on
Linux
may
be
compressed
dark.
Disabled
plus
L
toric,
like
just
doesn't
work
which,
which
would
indicate
that
nobody's
using
that
combination.
B
I
know
that
the
encryption
work
changed
how
some
of
the
feeding
and
reading
back
from
the
L
2
are
quirks
to
support
encryption
and
so
on,
and
so
it's
quite
a
bit
different
from
the
code.
That
I
did
all
my
original
testing
on
on
FreeBSD
II,
which
was
from
before
the
crypto
stuff
and
I
had
hoped.
The
crypto
stuff
might
have
the
answer
for
the
problem,
but
it
seems
it
might
actually
have
a
worse
version
of
the
problem.
A
So
was
there
any
more
kind
of
summary
of
the
existing
discussion
that
you
wanted
to
bring?
You
know
I
kind
of
agree
with
you
that,
like
people
have
people
have
raised
theoretical
concerns
that
seem
like
theoretically
valid,
but
you
know
definitely
we
were
kind
of
trading
off
here
between
implementation,
complexity
and
ability
to
add
new
features
and
improve
existing
compression,
algorithms
and
stuff
versus
you
know
some
some
performance.
If
folks
have
made
this
change,
you
know
have
changed
this
tunable
and
are
really
taking
advantage
of
it.
A
So
I
think
the
the
most
useful
thing
would
be
feedback
telling
us
like,
oh
actually,
we're
using
like.
We
need
to
be
able
to
disable
the
compressed
arc,
because
this
is
the
workload
that
we're
doing
and
it's
really
important
for
us,
and
then
you
know
that
we
kind
of
let
us
know.
Okay,
we
really
shouldn't
rip
this
out.
A
H
H
See
the
tenancy
of
the
artist
substantially
increased.
In
fact
we
we
have.
We
did
some
performance
investigation
at
some
point
where
there
were
recommendations
to
increase
post
grows
this
buffer
size
at
the
expense
of
the
arc,
but
actually
we
get
better
tenancy
from
the
arc
because
it's
compressed
so
actually
shrinking
the
post
grows.
Buffers
enables
more
because
you
know
you
get
between
one
and
two
times:
good
banker,
bark
in
terms
of
actual
cash
data
and
in
the
compressed
arc.
B
And
that's
similar
to
what
George
found
when
he
wrote
the
feature
originally
I
think
it
was.
They
had
a
working
data
set
that
was
close
to
a
terabyte,
but
the
Machine
couldn't
physically
take
more
than
seven
hundred
and
sixty
eight
gigs
of
RAM
and
then,
as
soon
as
they
turned
on
the
confess'd
arc,
it
all
fit
in
four
hundred
something
gigs
of
Arc
and
everybody.
Happy
I,
don't
think
the
implementation
complexity
of
a
toggle
for
compressed
arc
is
that
bad?
Basically,
it's
there's
a
check
in
a
bunch
of
places
in
the
arc
is.
B
Is
this
block
compressed
since,
because
compressed
arc
has
to
support
the
fact
that
the
block
on
disk
might
not
have
been
compressed
and
stare
for
whilst
a
uncompressed
in
the
arc?
Anyway?
There's
not
much
implementation
complexity
to
taking
the
ability
to
disable
to
compress
start,
but
it
is
in
this
case,
possibly
creating
more
complexity
with
other
features
that
might
have
a
weird
interaction,
although
all
of
those
seem
to
be
around
the
l2
arc,
and
maybe
the
solution
is
to
fix
the
l2
arc.
I,
don't
know,
I
think.
H
A
The
the
issues
that
you
know
you
would
remove
a
lot
of
the
complexity
and
the
complexity
with
respect
to
the
l2
arc,
and
also
the
constraints
that
we
have
to
put
on
ourselves
with
the
compression
algorithms
right,
because
we
need
because,
because,
if
you
disable
the
compressed
arc
and
you
have
an
l2
arc,
then
we
have
to
be
able
to
like
regenerate
the
original
compressed
data.
When
we
read
into
the
outer
arc,
we
have
to
be
able,
like
we
have
to
have
the
original
compression
algorithm.
A
So
you
know
you
would
have
to
if
you
wanted
to
like
update
your
lz4
algorithm
in
a
way.
That's
like
D
compatible
with
the
decompression,
but
it's
you
know
smarter
about
how
it
compresses,
maybe
use,
is
like
a
big
uses,
a
little
bit
more
memory
to
for
the
like
tables
that
it's
generating
or
whatever.
Then
you
have
to
be
able
to
do
it
both
ways
in
order
to
get
the
old
data
and
you
have
to
be
able
distinguish,
like?
A
A
Be
I
think,
prime,
that's
primarily
the
convent's
that
I'd
like
to
avoid,
because
that
spreads
out
to
more
of
the
rest
of
the
system
right
like
that
having
the
all
to
work
have
to
recompress.
It
is
like
it's
annoying,
but
it's
constraint
it
L
to
arc,
which
you
know.
It's
not
exactly
like
the
most
beautiful
piece
of
code.
Anyways
so
like
that,
that's
not
a
huge
deal.
It's
it's
more!
B
M
It
just
the
last
moment,
I'd
like
to
add
the
comments
that,
unless
something
change
it,
we
probably
still
don't
have
mechanism
to
directly
read
the
right
data
to
dark
buffer,
a
BT
buffer,
bypassing
Jim
UK,
which
means
we're
still
doing
another
memory
copy,
which
probably
cost
half
of
the
compression
time
which
makes
disabling
the
compression
is
close
to
pointless
the
purpose.
It
is
a
difference,
but
not
as
dramatic
as
it
could
be.
B
That
was
something
I
want
to
look
at
for
said
standard
in
particular.
Is
it
has
some
function
where
I
might
actually
be
able
to
take
the
scatter
gathered
list
of
something
like
a
BD
and
act
on
it
instead
of
us
having
to
make
a
linear
buffer
before
we
feed
it
to
the
compression
or
decompression
algorithm,
which
might
be
an
advantage
there?
B
A
May
help
we
did
some
research
on
that,
a
while
back
for
lz4
and
kind
of
like
what
aleksandr
was
saying.
The
like
Ferrazzi
for
at
least
the
difference
between
just
doing
an
eCopy
and
doing
le
for
decompress
was
pretty
small,
so
eliminating
the
copy
like
when
you
do
that
was
Li
for
decompress
we're
like
first,
we
copy
it
the
compressed
data
to
be
linear,
and
then
it
we
decompress
it
and
basically
eliminating
that
copy.
A
A
Cool
so
George,
do
you
want
to
talk
about
the
platform-specific
share
in
the
fest?
This
is
something
that
George
brought
up,
I,
think
last
meetings
and
finally
sent
out
the
specific
proposal
yesterday,
I'm
not
sure
how
many
had
a
chance
to
read
it
before
this
meeting.
But
maybe
do
you
want
to
summarize
what
the
proposal
is
and
then
you
maybe
summarize
the
existing
feedback,
sure
SiC.
N
Okay,
great
connection,
so
so
yeah
the
concern
originally
when
we
started
this
discussion
was
that
there
are
certain
properties
which
are
on
on
this
component,
that,
when
you
were
to
import
a
pool
would
cause
ZFS
to
take
certain
actions.
And
if
you
start
doing
this
across
platforms,
it
was
kind
of
undefined
what
that
behavior
would
be.
So
if
you
brought
in
an
illumise
pull
that
had
some,
you
know
platform
specific
property.
What
would
it
do
when
it
came
on
FreeBSD
or
Linux?
Is
that
you
know
something
that
we,
you
know
need
to
be
concerned
about?
N
N
So
the
proposal
that
I
put
out
there
was
to
try
to
create
a
platform
specific
infrastructure
for
properties
that
would
allow
you
to
define
different
behaviors
based
on
a
platform,
and
so
this
way,
if
you
were
to
import
pool
that
say,
for
example,
had
Sharon
FS
set.
It
would
recognize
that
the
Sharon
FS
property
had
been
set
on
a
different
platform
than
the
one
you're
importing
on
and
would
simply
ignore.
N
Whatever
contents
were
there,
and
likewise,
you
know,
would
only
get
read
and
evaluated
when
it
came
in
on
a
platform
that
it
was
originally
written
on
or
that
it
was
intended
for
so
that
was
kind
of
what
I
sent
out.
I
would
say
right
now.
You
know
it's
probably
early
on
the
feedback
that
has
been
provided.
I
think
you
know.
Initially
it
was
well.
We
really
shouldn't
have
this
kind
of
functionality,
and
we
should
just
allow
the
vendors
and
distros
to
kind
of
decide
how
they
want
to
implement
these
types
of
properties.
N
I
think
there's
some
drawbacks.
There
I
think.
Ok,
my
back.
Can
you
hear
me?
Okay,
sorry,
so
I
think
I
think
with
user
defined
properties
as
the
community.
If
we
want
to
go
that
direction,
it
really
starts
to
go
towards
a
path
where
we're
deprecating
those
features,
because
then
anybody
can
define
them
the
way
they
want.
The
code
doesn't
really
need
to
live
in
ZFS.
N
If
it's,
if
it's
important
for
us
to
have
these
types
of
properties,
I
think
they're
really
or
you
know,
to
take
action
on
some
of
these
types
of
features
like
NFS
or
I,
scuzzy
or
SMB
I.
Think
that
needs
to
be
closely
tied
to
ZFS
and
probably
needs
to
remain
as
it
as
a
native
property,
again
kind
of
my
opinion,
so
I
think
the
feedback
so
far
has
been
kind
of
mixed.
N
There's
kind
of
a
couple
tweaks
to
the
proposal,
but
I
think
they're,
all
kind
of.
In
the
same
day,
we
would
try
to
come
up
with
some
kind
of
nomenclature
that
would
tie
a
prop
a
property
to
a
specific
platform
or
distro
the
granularity.
There
I
think
we
can
all
decide
on.
You
know
how
granular
we
wanted
to
make
it,
but
overall
I
think
if
we
want
to
have
a
platform
specific
property,
it's
the
infrastructure.
You
know
can
accommodate
that.
So
I
think.
D
N
A
A
What
was
it
really
about
like
the
like
a
command
line
flag
to
specify
the
operating
system
as
it
was
to
like
the
wet
Georgia
said
about
like
a
suffix
on
the
property
name,
or
was
there
like
some?
It
was
there
an
additional?
You
know
functionality
functional
difference
from
what
George
was
proposing.
That
I
was
missing
there
well.
H
So
I
I
think
the
the
biggest
material
difference
in
the
way
the
properties
would
be
applied
was
that
I
was
suggesting
that
we
could
also
have
a
like
if
you
wanted
to
keep
for
whatever
reason
the
the
way
that
it
works
today
that
you
could
basically,
but
that
by
default
we
would
arrange
it
so
that
it
did
not
work
that
way.
It
works.
H
Basically,
the
way
that
George
is
describing,
but
with
a
slightly
different
veneer,
essentially
on
top
basically
from
an
interface
perspective
like
I,
think
that
we,
rather
than
add
a
bunch
of
new,
alias
alias,
is
where
the
name
is
included
in
the
property
name.
I
think
we
could
make
it
like
a
field,
that's
sort
of
mostly
hidden
from
people
most
of
the
time.
Basically,
and
we
could
probably
do
that
without
changing
any
of
the
api's,
even
though
the
libraries
really
like
we
could
add
new
api's.
H
If
you
wanted
to
manipulate
like
you,
could
add
an
extra
field.
If
you
wanted
to
manipulate
that
specifically,
but
I
think
that
in
general
you
would
just
be
operating
on
the
properties
from
your
particular
operating
system,
which
again
is
quite
similar
to
what
George's
I
think
I
think
it's
a
good
idea
like
the
accomplice.
H
A
Agree
so
for
as
far
as
the
kind
of
material
difference
from
dirt
or
hosel
of
being
able
to
continue
doing
it.
The
old
way
in
you
know
I
mean
definitely
is,
is
the
use
case
for
that,
like
that,
like,
if
you're,
using
very
simple
Sharon,
if
estimate
value
variable
value
for
the
current
invest
property,
then
it
does
kind
of
work
more
or
less,
if
you're,
just
on
yeah,
that.
H
So
it
seems
like
the
way
to
go
to
have
to
effectively
not
try
and
translate
them
as
part
of
your
base
mechanism
and
and
because,
like
each
one
of
these
properties,
is
going
to
be
different
too
and
in
the
future
we
might
introduce
new
negative
properties
that
are
only
interesting
on
one
operating
system
and
I.
Think
that
that's
fine
yeah,
like.
H
A
We're
making
sure
that
it
makes
any
sense
or
so
I
think
that's
what
makes
it
really
operating
system.
Specific
I
mean
you
could
imagine
you
know
thing
you
could
imagine
like
if
we
had
indeed
a
different
way
or
for
some
future
thing,
like
let's
say
like
share
AFP
right,
like
Apple,
share
protocol,
we
we
could
say
okay,
like
that.
Actually
the
value
is
something
that
ZFS
knows
about
right,
like
you
said,
Atlas
sure
equals
like
you
know,
purple
and
like
purple,
is
something
that
ZFS
knows
like
okay,
great,
like
all
of
your
files.
A
When
you
share
it
we're
gonna
become
purple.
Like
you
know,
you
look
in
the
finder
and
now
there
have
a
purple
tint
on
that
and
as
long
as
the
ZFS
is
the
one
interpreting
that
and
implementing
it,
then
like
that
really
makes
sense.
And
if
you
read
some
other
platform
that
doesn't
support
purple,
then
it's
like
well
like
where
it
says
like.
If
I
equals
purple,
then
you
just
like
knock
that
out
or
or
whatever.
But
the
thing
is
problematic.
Is
that
we're
not.
H
D
H
That
we
don't
have
to
keep
changing
ZFS
exam,
we
add
new
mount
flags,
you
know
it's
just
like
you'd
have
to
basically
have
implemented
like
a
NFS
export
like
domain-specific
language.
Basically,
you
know
that
you,
you
know
and
then
and
then
it
would
need
to
expand
to
cover
all
of
the
options
that
exist
and
all
the
different
configurations.
So
it's
I
mean
it's
I
can
see
why
it
was
done.
The
way
that
it
was
yes,
I.
A
B
F
A
A
A
B
H
I
think
critically
you
each
operating
system
or
distribution
or
whatever
would
would
in
this
world,
hopefully
be
able
to
pick
which
properties
they
demonstrate
as
being
a
first-class
one.
Yeah
so
like
you,
could
just
totally
opt
out
of
having
share
I
scuzzy
altogether
on
your
platform,
for
instance,
if
you
don't
want
to
support
it,
and-
and
you
could
arrange
to
have
it-
be
an
error
to
set
it
on
a
platform
that
doesn't
support
it
without
also
specifying
which
other
operating
system
you
know
and
then
just
like
any.
A
Seems
like
you,
it
might
not
be
super
elegant,
but
you
could
easily
extend
this
to
like
if
we
decide
it's
going
to
be
per
operating
system
and
then
you're
like,
oh
but
like
on
my
linux
distro.
Actually
we
do
it
differently
and
the
string
doesn't
make
sense
from
other
things
to
suppose
it's
like
very
fine.
B
H
H
H
A
H
B
On
that
and
Richards
notes
about
things
like
Samba,
which
are
could
be
the
same
across
all
but
illumos,
the
SMB
server
is
different.
Maybe
it
even
make
sense
to
just
combine
the
three
of
these
into
just
a
share
property.
You
just
have
share
at
previous
DNFs
and
share
at
Samba
and
the
sample
one
would
work
everywhere.
You
have
Samba,
or
you
know,
share
at
the
Lumos
SMB
I,
don't
know
if
it
makes
sense,
but
making
it
less
tied
to
the
OS
and
more
to
the
implementation
of
the
sharing
protocol.
B
H
B
E
A
A
Yes,
exactly
so
like
when
you
do
ZFS,
rename
or
ZFS,
you
know
set
whatever
random
property,
we
go
and
we
go
in
like
unshare,
and
then
we
share
it
later,
and
so
that's
why
it
needs
to
be
a
system
property
and
then
it
needs
to
be
a
platform
specific
property,
because
we
are
validating
that
string.
We're
just
tuning
down
to
the
OS
utility.
L
Regards
to
hooks
and
error
management
like
gosh,
you
mentioned
that
you
might
want
to
see
rich
error
handling.
So,
for
example,
if
a
property
is
not
available
on
a
certain
platform
that
you
would
actually
not
just
accept
the
write,
but
instead
return
an
error
and
say
this
is
not
possible
on
this
platform.
L
A
I
think
I
understand
your
proposal.
Was
it
your?
Are
you
saying
that
we
should
provide
some
like
ZFS
should
be
validating
the
stream,
then
just
pass
it
down
to
the
its
operating
specific
share
utility,
and
then
we
should
be
validating
by
having
simple
do
a
plugin
that
lets.
You
provide
the
validation
code,
yeah.
L
That's
basically
it
so.
The
the
most
general
form
of
this
proposal
would
be
to
have
no
platform
specific
cooks
in
the
ZFS
core
code
base,
but
instead
have
a
generic
interface
to
invoke
books
that
are,
for
example,
written
in
Lua.
So
we
could
do
the
NFS
aunt,
Raya
and
re
sharing
in
Lua,
but
also
validation
of
the
messages
that
we
put
in
there.
L
Think
I'm
thinking
about
the
the
platform
support
like
consider
different
Linux
distributions
and
also
the
additional
dimension
of
different
NFS
serve
us
different
SMB
implementations,
different
I,
scuzzy
implementations
I
can
see
a
pretty
big
patch
set.
That
is
unique
per
distribution,
not
just
the
operating
system,
but
third
distribution
to
actually
support
that.
L
If
we
want
to
have
the
property
as
a
plain
string
and
not
to
anything
specific
about
it,
fine,
but
if
we
have
these
system
back
properties,
so,
for
example,
setting
the
NFS
share
attributes
or
something,
as
you
said,
we
need
to
do
something
in
the
moment
that
properties
that
and
I
think
the
the
amount
of
combinations
explodes.
If
we
say.
Ok,
we
allow
all
these
different
combinations
of
distribution
and
software
versions
of
software
variants.
A
L
Am
Not
sure
I
can't
spend
the
time
one
day,
I
think
just
like
I
think
it
is
the
risk
that
we
have
to
bake
out
of
this
and
like
one
or
two
years,
when
all
these
different
variations
are
present
and
are
out
there,
then
it
will
be
harder
to
consolidate
then,
because
every
distribution
will
have
an
individual
page
for
their
particular
needs.
Yeah.
A
L
J
To
make
it
a
bit
simpler,
how
about?
How
do
you
guys
are
going
back
to
the
hooks?
How
do
you
guys
think
the
hooks
should
be
implemented?
For
example,
it
should
be
just
because
it
could
be
to
some
extent
just
the
property
could
could
have
like
value
extension,
where
you
put
the
string
and
also
like
handle
extension,
where
you
put
the
path
to
executive.
All
that
will
be
passed
this
drink
once
the
property
changes
or
something
like
that,
or
do
you
think
more
about
like
library
call
or
what
does
there
be
a
idea
behind
it?
J
L
Think
it
is
an
interesting
idea
to
have
the
hook
be
acceptable
by
the
user,
but
I
think
it
would
like
take
a
little
bit
of
magic
out
of
the
whole
thing.
So
I
would
expect
as
a
user,
that
there
be
a
default
hook
and
that
hook
would
be
like
the
distribution
specific
and
if
I
have
even
more
custom
needs,
then
maybe
I
could
override
the
hook.
L
B
Then
we
end
up
back
in
the
same
situation
where
the
parameters
for
the
illumos
NFS
hook
are
not
understood
by
the
freebsd
NFS
hook,
whereas
if
we
kind
of
encode
as
part
of
the
value
which
thing
is
responsible
for
interpreting
it
and
you
import
it
on
one
where
that
doesn't
exist,
then
we
just
ignore
it
or
something.
No.
L
A
All
right,
well,
I,
think
that's
good
feedback
and
we're
out
of
time.
Sorry
question
we
didn't
get
to
your
blasted
in
item.
We'll
add
it
for
next
for
a
next
month
next
month
of
May,
so
the
next
meeting
should
be
March,
26
well,
I,
think
next
month.
We'll
do
this
time
again
and
then
maybe
the
one
after
that
we'll
do
it
earlier.
So,
like
maybe
two
two
at
this
time
and
then
one
at
the
earlier
time,
it
seems
like
both
times
works
for
a
lot
of
people,
so
that
would
be
good
and
thanks.