►
From YouTube: Second March 2020 OpenZFS Leadership Meeting
Description
At this month's meeting we discussed: Deprecate dedup send/receive; new ZFS admin API; O_DIRECT semantics.
Details and meeting notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit#
A
Okay,
cool,
it
looks
like
it's
one
after
the
hour.
Welcome
everyone
to
the
working
from
home
edition
of
the
opens
defense,
leadership,
meeting,
I,
hope,
you're,
all
staying
safe
and
socially
distance.
If
not
isolated,
let's
get
started.
We
have
a
bunch
of
the
interesting
topics
for
today.
So
the
first
one
on
the
agenda
is
my
topic.
A
A
So
the
next
release
of
0-8
will
have
those
messages
in
there
and
I
have
a
PR
open
to
add
a
utility,
Z
stream
and
the
sub
commitment
of
that
Z
stream,
redo
p--
to
take
a
duplicated,
sent
stream
and
turn
it
into
a
normal
one,
so
that
you'll
still
be
able
to
receive
any
old
d,
dupes
and
streams
that
you
have,
or
you
know,
generate
those
kind
of
those
d
dupes
and
streams
on
systems
with
older
software.
That
still
has
it
and
receive
it
on
newer
software.
A
You
know
indefinitely
so
that
PR
is
open
if
folks
have
feedback
on
the
design,
the
user
interface
and
now
would
be
a
good
time
to
get
feedback
in
I
also
incorporated
the
functionality
of
Z
stream
dump
into
the
new
command.
So
now
it's
Z
stream,
space
dump
and
Z
stream
dump.
One
word
is
maintained
as
a
an
alias
to
keep
doing
what
it
was
doing
before.
A
So
it'll
it'll
live,
you
know,
kind
of
next
to
Z
stream
dump
and
the
ZFS
command
and
all
the
other
stuff
cool
I
mean
it's
it's
pretty.
It
doesn't
have
a
lot
of
dependencies
like
most
of
the
code
is
just
like
in
the
one
you
know
it
does,
link
with
the
ZFS
but
kind
of
makes
minimal
use
of
it.
So
it
shouldn't
be.
You
know
we
shouldn't
have
to
do
a
lot
of
work
to
maintain
that
kind
of.
Similarly,
with
the
Z
stream
dump,
like
it
just
kind
of
sits
there
and
works.
A
C
C
C
All
right
so,
first
question
right:
what
exactly
is
this?
We
already
have
libs
EFS
libs
EFS
cor.
What's
this
additional
librarian?
What's
the
point
so
essentially,
it
would
be
like
an
alternate
API
for
applications
to
integrate
with
ZFS.
It
would
essentially
have
a
set
of
functions
equivalent
to
what
the
CLI
commands
provide.
I'd
be
like
zpool,
create
sequel,
destroy
list.
All
those
different
functionalities
would
have
an
equivalent,
but
the
main
deal
would
it
doesn't
need
to
be
exactly
equivalent.
C
C
They
essentially
call
out
to
all
the
CLI
utilities,
zpool
ZFS
and
then
parse,
that
output
back
to
some
data
structure
that
matches
something
they
have
I'd
like
to
see
if
we
could
have
an
API
that
they
would
use
this
instead,
there's
some
stuff
in
the
CLI
utilities,
some
business
logic
there
I'll
get
into
a
bit
later
that
if
you
were
to
try
to
mirror
exactly
what
the
CLI
is
doing,
you'd
have
to
add
some
additional
fluff.
What
Lib,
ZFS
and
live
ZFS
core
provides,
so
this
layer
could
accommodate
that.
C
Also
when
you're
calling
a
library
rather
than
shelling
out
to
ZFS
or
Z
pool,
you
have
a
lot
less
overhead
and
for
me
personally,
I
like
to
keep
what
I'm,
using
usually
native
to
the
exact
language
I'm
in
and
not
shell
out,
if
possible.
So
this
would
be
really
great
one
thing:
that's
really
cool
would
be
very
consistent
expectations
between
what
happens
when
you
do.
We
see
I
command
and
exactly
what
happens
with
the
API.
This
is
very
akin
to
kind
of
what
AWS
has
done
with
their
API.
A
Right
if
I
interrupt
a
Squasher
motivation,
just
to
clarify
so
it
sounds
like
part
of
this-
is
that
it
were
well
as
part
of
this
that
people
are
familiar
with
how
to
administer
ZFS
using
the
CLI
and
then
they're
like
now.
We
need
to
write
a
program
to
do
what
I
used
to
do
with
a
shell
script,
or
you
know
whatever,
like
my
product,
needs
to
integrate.
A
On
the
CLI,
I
want
to
have
like
a
easy
as
simple
as
possible
kind
of
translation
of
like
at
the
Cielo
I
type,
whatever
you
know,
ZFS
whatever,
whatever
and
I
want
my
program
to
do
it,
but
I
don't
want
to
have
to
do
with
like
parsing
a
bunch
of
command
output,
or
you
know
a
fork
exec.
You
may
suddenly.
C
C
A
C
C
A
C
B
B
C
A
C
A
Tricky
thing
about
implementing
this
is
like,
on
the
one
hand,
you're
saying
you
can
do
just
the
same
thing
as
if
yeah,
as
as
the
CLI,
in
which
case
like
great
like
the
Cielo,
is
already
using
live
ZFS.
So
we
just
like
you
know,
move
a
bunch
of
stuff
from
ZFS
main.c
into
the
library
and
then
job
done.
But
then
you
have
all
the
same
behavior
of
libs
ZFS.
So
like.
D
A
You
don't
like
the
fact
that
if
you
think
there's
missing
functionality
in
live
ZFS,
then
I
think
this
kind
of
makes
sense.
But
if
you're
saying
Lib
ZFS
does
the
wrong
things,
then
you
can't
just
like
take
this
CLI
and
and
you
and
use
that
code,
because
that
is
using
live
ZFS
right.
So
you
know
if
flip
ZFS
is
like
printing
a
standard
error
and
you're
like
I'm
on
my
new
utility,
my
new
libraries,
not,
for
instance
temp
in
dust
and
air,
then
you
got
to
go,
find
all
the
you
know.
A
You
knew
your
new
library
is
gonna,
be
using
live
ZFS.
Presumably,
since
that's
what
the
CLI
is
doing
so
now
you
have
to
go
find
everything
in
the
DFS
that
doesn't
do.
That
does
stuff
that
you
don't
want
by
totally
exiting
or
printing
or
whatever,
which,
like
I,
don't
think
if
that
is
as
ubiquitous
as
it
might
be
made
out
to
be,
but
there's
definitely
work.
C
To
do
there
and
totally
agreed
I
was
intending
that
to
be
part
of
this,
to
essentially
modify
those
places.
So
there's
always
a
consistent
return
up
of
an
error
code,
slash
description
rather
than
anything
being
outputted
I,
don't
think
that's
super
far
across
the
board,
but
there
are
places
where
it
happens,
so
that
was
kind
of
stuff
like
okay,
I
would
change
Lib
ZFS,
but
at
the
same
time
I
don't
know
who
consumes
that.
So
there's
those
questions
I,
don't
want
to
break
anybody
who's
expecting
that,
yes,.
B
E
Going
to
say
one
of
the
things
we're
always
told
his
limbs,
EO
v
Gore
is
API
stable.
That
libs
DFS
is
not
right,
so
this
new
thing
could
be
stable.
I
would
be,
as
I
said,
when
the
chat
thing
I
would
be
totally
in
favor
of
that,
because
we
wrote
a
we
and
I
presume
many.
Other
people
have
written
Python
interfaces
for
that
FS
and
he'd
be
nice
to
have
it
simplified.
C
D
Repower
actually
already
exposes
a
lot
of
API
surface,
for
example
the
Python
bindings,
although
they
are
contrary
the
already
show
how
much
work
it
is
and
how
much
duplicate
code
there
is,
for
example,
for
figuring
out
what
exactly
a
system
called
error
means
in
the
context
of
a
particular
system
coil,
or
that
code
is
already
duplicated
in
the
PI
CSS
bindings.
If
you
can
call
them
bindings,
because
there's
actually
a
lot
of
logic
in
there.
So
I
think.
D
One
key
aspect
that
is,
we
figured
out
before
we
write
yet
another
library
that
exposes
the
other
functionality
in
a
different
way
is
how
we
transport
errors
from
user
space
from
using
space.
I
think
we
already
talked
about
this
a
few
months
ago,
but
there
are
a
lot
of
points
than
use
the
space
where
the
corner
of
the
system
coil
needs
to
figure
out
what
the
system
called
return.
Value
means
based
on
the
context
that
it
did
like,
for
example,
e
exists
or
e
in
Vilas
heavily
overloaded.
C
D
E
D
Also
yet
another
thing
that
I
was
like
I
talked
to
a
few
people
at
the
last
to
developer
summits
about
that
I
have
a
like
experimental
patch.
That
is
halfway
done,
but
it
has
been
sitting
around
for
such
a
long
time
that
I,
don't
think
it
would
be,
would
apply
now,
but
I
think
it
would
be
pretty
awesome
to
have
a
stable
kernel
interface
that
is
based
on
just
in
envious.
So
we
put
in
an
envious,
twee
get
out
and-
and
we
list
and
that's
all
that
is
to
it,
then.
D
A
But
that's
like
a
very
different
goal
than
what's
being
discussed
here,
because
those
those
axles
are
way
lower
level
than
what
the
see
lies
does
we're
like
imagine,
you're
like
ZFS,
create
Oh
bah,
bah,
bah,
bah
bah
ho.
You
know
file
system,
there's
a
lot
of
like
parsing
of
that
stuff
before
you
can
get
down
to
the
end
of
your
list
or
like
how
about
ZFS,
destroy
ZFS
destroy
capital
are
something
something
with
a
percent
in
it.
A
So
you're
doing
like
a
range
you're
going
to
range
of
snapshots
and
each
thing
that's
below
this
point
and
all
their
clones
and
whatnot
like
that's,
and
maybe
you
do
like,
and
you
just
want
to
get
like
the
list
of
what
it
would
do
like
there's
a
lot
of
stuff
there.
That
is
not
it's
like
a
lot
of
different
iocked
holes.
To
put
that
all
together,
I
mean
that's
that's
why
the
live.
A
B
B
D
C
All
right,
I'm
gonna,
move
forward
unless
someone
to
get
something
else.
Okay.
So
what
exactly
does
this
look
like?
I
just
did
some
preliminary
looking
through
what's
available
in
Depot
Maine
GFS
Maine,
there's
a
lot
of
forward
declarations.
Do
ZFS
asterisk,
so
do
zpool
asterisks
that
kind
of
make
up
the
different
CLI
commands
I
kind
of
just
tried
to
one
on
one
to
one
that
those
as
much
as
possible
Matt
had
brought
up
something
use
cases
where
maybe
it
doesn't
make
sense
to
be
one-to-one.
C
So
if
it
doesn't
make
sense,
we
shouldn't
do
it
that
way,
but
by
and
large
this
is
kind
of
the
idea.
Any
business
logic
that's
present
in
zpool
or
ZFS
kind
of
gets
shoved
down
to
the
lip
ZFS
api
layer.
This
be
anything,
that's
not
really.
A
CLI
related
concern,
zpool
and
ZFS
would
attempt
to
use
live
ZFS
api,
where
possible.
C
Not
only
would
this
provide
usage
of
the
library
and
how
to
use
it.
It
also
gives
you
test
coverage
over
any
changes.
We've
made
because
there's
a
lot
of
backing
tests
to
validate
zpool
and
ZFS
the
live
ZFS.
Wouldn't
our
lib
GFS
api?
Wouldn't
output
the
standard
error
standard
out
you
just
return
error
codes
and
descriptions,
leaving
the
client
in
charge
of
how
to
output
that
if
it
was
a
rest
server,
the
rest
of
would
return
a
JSON
err
format
text
right.
C
C
If
you
look
at
Z
pool
just
destroyed.
This
is
oh
sorry,
let's
pop
back,
if
you
look
at
z,
p--
will
destroy
it's
fairly
straightforward.
It's
kind
of
a
simple
contrived
example,
but
I
think
it
will
prove
to
be
useful
for
this.
The
main
piece
here
really
is
the
disabled
datasets.
This
is
kind
of
a
validating.
Things
are
good
beforehand,
making
sure
all
of
the
data
sets
are
unmounted
and
an
additional
logic
there
before
we
attempt
would
destroy
if
you
were
to
duplicate
this
just
looking
again
slip.
C
Zfs
you'd
have
to
make
this
call
yourself
beforehand.
Anyways.
This
is
just
a
simple
piece
of
business
logic
that
I
think
could
be
pushed
down
other
pieces,
the
open
and
closed
I.
Don't
think
it
really
needs
to
live
at
this
layer.
There's
nothing
specific
as
to
why
this
needs
to
be
here,
at
least
within
what
I've
looked
at
so
far.
There
might
be
other
cases
where
this
proves
me
wrong,
but
for
this
case
I
think
it
can
push
down.
C
So
essentially
what
this
ends
up
looking
like
if
we
were
to
rewrite
this
with
the
changes
is
now
so.
This
ellipses
here
is
basically
CLI
parsing
clicking
too
much
here.
This
is
the
CLI
parsing.
We
get
the
pool
name,
we
call
our
libs
ZFS
API
pool,
destroy
which
just
takes
the
name
of
the
pool,
whether
we're
forcing
it
or
not,
and
the
history
string
I,
don't
remember
the
history
strings
for,
but
it's
part
of
the
call
down,
it
returns
an
heir
code
and
we
decide
what
to
do
from
there.
C
So
if
we
didn't
succeed
in
destroying
the
pool,
we
follow
some
of
the
same
logic
from
beforehand.
If
there
was
a
slash
in
there,
we're
assuming
hey,
you
really
meant
to
destroy
a
volume.
You
should
probably
call
ZFS
if
we
failed,
otherwise
we're
gonna,
try
and
relate
that
back
up.
This
is
not
equivalent
output
to
what's
there,
that's
a
little
more
complicated
to
hit
equivalent
output,
which
would
be
another
hard
part
of
this,
but
essentially
we'll
try
and
use
that
error
code
to
output.
A
C
A
B
Probably
wanted
to
sort
of
two
things:
I
think
you
want
that
string
like
so
I
think
this.
The
string
that
the
CLI
would
emit
today
should
come
out
as
a
property
in
an
error
object,
but
it
would
be
good
to
be
able
to
support
other
properties.
You
know
like
if,
if
the
destruction
for
like,
if
the,
if
the
destruction
fails,
because
it
can't
unmet
a
particular
file
system
or
a
particular
set
of
file
systems,
you
can
have
a
list
of
those
file
systems
or
the
data
sets
or
whatever.
B
C
B
B
They're
all
sort
of
limited
in
that
like
once
it's
there.
It's
kind
of
it's
difficult
to
evolve
that
interface,
but
whereas
here
you
could
have
like
lzj
a
pill,
destroy
a
handle,
pool
history
stream
force,
and
then
you,
you
know
if
it.
If
it
doesn't
go
well,
you
could
have
like
get
era
nvl
or
get
arrow
list
of
devices
or
something
like
we
could
add,
additional
symbols
that
refer
back
to
the
handle
and
look
at
the
the
furthest
state
of
the
last
operation.
C
B
E
B
F
A
F
F
C
Essentially,
we've
pulled
down
the
Z
pool
open,
does
equal
close.
The
disabled
data
sets
is
in
here
now,
Lib
ZFS
API
maintains
its
own
handle
to
live,
ZFS
we're
in
live
ZFS
core,
where
applicable
and
essentially
would
return
air
goes,
but,
as
we've
discussed,
the
air
stuff
is
going
to
evolve
and
be
different.
This
is
essentially
the
idea,
and
then
you
would
have
total
understanding
of
what's
possible
to
return
what
those
things
mean,
if
you
so
we're
going
to
use
the
air
code
I,
don't
even
know
that
this
perfectly
reflects
what
it
is
with.
B
B
A
Think
you
know
my
kind
of
takeaway
from
this.
Is
that,
like
this,
this
solves
the
Rugal
problem
and
I
think
they.
It
is
doable.
I
think
that
the
bulk
of
the
work
here
is
in
the
error
handling,
like
that's
kind
of
that's,
probably
where
the
BFS
is
weakest.
You
know
moving
the
code
around
from
libs
from
you
know,
ZFS
Mincey
into
a
library
is
like
not
that
hard
mm-hmm.
B
To
see
this,
and
as
far
as
I
think
up
front
careful
up
front,
a
bi
design
will
be
important
too
in
order
to
be
able
to
make
it
from
from
the
first
version
to
make
it
a
stable
library
that
we
think
it
would
be
important
to
make
sure
that
we
don't
make.
There
are
a
number
of
like
subtle,
C
and
an
elf
realization,
design
issues
with
say
below
P
a
a
B
ice
rather
than
an
API
switch
I.
Think
we'll
just
want
to
make
sure
we
don't
accidentally
tickle
those
thank
you.
Yeah.
B
A
In
reality,
we
probably
would
like,
if
I,
had
it
to
do
over
again
and
had
the
time
I
would
have
like
if
we
didn't
have
the
time
to
make
a
real
API
like
we
could
have
just
put
all
of
that
stuck
not
even
making
Lib
CFS
and
just
have
like
one
giant
binary
that
you
can
invoke
by
calling
a
ZFS
or
Z
pool
or
whatever.
You
know,
because
that's
kind
of
more
honest
about
what
how
that
code
is
really
structured.
D
Have
a
remark
on
the
software
engineering
angle
on
that,
in
particular
about
the
the
error
handling
case,
so
they
are
definitely
it's
out
there,
including
zero
booze,
but
there
are
also
a
lot
of
other
spirits
that
rely
on
screen,
scraping
the
air
output
for
proper
error
handling
and
the
like
a
few
classics.
Our
data
set
does
not
exist
and
all
these
kinds
of
errors,
it's
very
important,
that
these
remain
stable.
D
So
as
an
idea
for
making
sure
that
we
don't
have
any
regressions
in
that
regard,
I
would
propose
that
we
start
recording
the
output
of
standard
out
and
standard
error
of
the
entire
ZFS
test
suite
or
at
least
of
the
the
subset
of
the
ZFS
test
fit
well.
That
makes
sense
and
put
that
somewhere,
I,
don't
know
whether
in
the
repository
itself
or
in
get
the
FS
or
something
and
have
that
be
the
baseline
for
any
regressions
with
regards
to
error,
reporting
and
I.
Think
they
like
it
like
it
introduces.
This
feature
should
do
that.
A
A
That's
a
great
example,
so
I
think
that
I
would
I
think
I
would
definitely
recommend
implementing
something
like
what
Christian
said.
Just
like
record
the
output
of
all
the
commands.
When
you
run
the
test
suite
and
then
do
another
run
and
be
able
to
dip
those
so
that
we
can
know
what
was
changed
and
then
apply
that
kind
of
case-by-case
judgment
call
on
whether
those
changes
are
okay
or
like.
If,
if
it's
easy
to
fix
it
up,
so
that
it
looks
the
same,
then
you
know
we
might
as
well
do
that.
Okay,.
D
Also,
another
point:
I
wanted
to
make
that
experience
then
developing
0po,
and
that
is
that
I
found
it
very
useful
to
have
internal
abstractions
that
are
it
important
and
I
think
if
we
just
move
these
commands
into
a
library
that
works
like
the
ZFS
commands,
we
don't
gain
anything
on
that
front.
Now,
there's
the
question
whether
it
is
like
if,
if
I'm
mistaken,
it
only
I
find
it
worth
having
it
impotent
api's,
but
in
general
I
find
it
very
useful
from
programmers
perspective
to
like
not
have
to
worry
about.
D
B
That
that
helps
sometimes
but
like
what
about
the
vast
amount
of
things
that
you
could
have
so
like?
Let's
say
you
create
the
data
set
and
then
that's
fine
and
it's
and
then,
but
then
you
go
and
like
set
a
bunch
of
properties,
make
some
changes
to
it
turn
the
compression
on
do
some
writes
whatever,
and
then
you
come
and
do
that
original
call
that
you
want
to
be
on
impotent
again.
B
Are
you
like
what,
if
that
call
like
what,
when
you
created
the
data
set,
if
you
had,
if
you
included
like
setting
the
compression
to
offer
on
or
whatever,
but
in
the
meantime
that
property
has
been
changed
like
does?
That
call
also
change
the
property,
and
would
you
want?
Can
you
imagine,
under
some
conditions
at
least
that,
like
a
strict
mode
where,
like
you,
would
want
to
know
that
the
thing
that
you'd
asked
for
hadn't
happened
or
had
happened,
or
something
in
basically
this.
D
Is
kind
of
a
transaction,
it
was
a
transactional
problem,
I
think.
Basically,
that's
the
I
would
not
only
have
the
other
pretend
api's,
but
there's
so
this
was
kind
of
a
open
up
for
a
bigger
thing.
That
is
what
I
do
internally
and
zero
bill
is
to
almost
everything
with
geo
IDs,
so
in
particular
snapshot
geo.
It
is
like
being
and
snapshot.
Reality
is
fast
and
geo.
Ds.
D
These
enable,
for
example,
say
free
names,
ZFS
rename
cannot
be
implemented
safely
like
you
can
never
know
whether
between
the
decision
that
you
want
to
make
the
rename
and
you
actually
issuing
busy,
as
called
to
make
the
rename
somebody
swapped
out
the
data
set
underneath
and
being
able
to
express
that
operation
with
G
IDs
instead
of
the
the
data
set
pass.
I
would
find
that
very
helpful
in
the
library
and
the
point
I'm
trying
to
make
is
I.
D
Don't
think
it's
a
good
idea
to
have
a
kind
of
lateral
movement
from
CLI
to
library,
but
instead
there
should.
We
actually
thought
going
into
what
is
useful
for
program
ability
because
sure,
like
in
the
99%
case,
the
password
finding,
but
if
you
have
concurrency
integuments
I,
know
that
then
I
think
it
would
be
very
useful
to
restructure.
A
lot
of
the
IP
is,
or
at
least
have
to
thought
in
mind
that
at
some
point
we
want
G
or
IDs
and
not
data
set
path.
D
B
B
Well,
I
guess
so
the
source
could
be
a
name
or
or
a
GID,
and
the
destination
would
have
to
be
a
name,
but
you
know,
and
then
you
could
add,
you
know
like
if
you
then
wanted
later
on
to
add,
like
an
idempotent
like
a
create,
if
not
exists
or
like
those
sorts
of
things,
you
could
add
those.
This
extra
properties
that
you
don't
have
to
necessarily
support
and
all
we'd
have
to
do
in
the
in
the
in
the
function
would
be
to
reject
properties
that
are
not
understood
as
being
invalid.
D
A
A
A
Could
you
put
together
like
just
kind
of
refine
down
further
your
proposal
in
terms
of
what
the
api's
will
look
like
and
maybe
come
up
with
a
couple
more
examples,
and
then
we
can
I
like
maybe
send
out
an
email
to
the
mailing
list,
and
then
we
can
get
some
more
discussion
on.
You
know
the
more
concrete
proposal
for
they
are
handling
and
all
that
and
deal
sounds
good
cool
thanks
a
lot
so
I'm
gonna.
Why
do
I
skip
the
well
well,
I'll
mention
their
direct
stuff
or
I'll
tee
up
if
Brian,
Brian
or.
A
A
I'll
keep
talking
until
somebody
and
meets
himself,
so
I
was
working
with
Brian
Brian
in
and
mark,
maybe
on
the
direct
support
which
we
talked
about
at
the
last
meeting,
and
it
folks
raised
some
very
good
concerns
there.
So
we
we
took
that
away
and
had
a
bunch
of
discussions
around
the
exact
semantics
that
we
wanted.
I
sent
out
an
email
with
a
summary
and
there's
also
a
design
document
that
kind
of
weighs
the
pros
and
cons
of
a
bunch
of
different
decisions.
F
A
Process
has
multiple
threads
and
one
of
the
other
threads
could
do
a
store
to
the
buffer
that
you're
using
for
the
for
the
direct
right.
We
want
to
make
sure
that
the
check
sum
or
like
in
an
you
know
in
a
simple
implementation
that
might
change
the
data.
What
like
in
between
when
we
do
the
check
sum
and
when
we
wrote
it
out
to
disk,
so
we
decided
that
if
you
have
checksums
enabled
or
are
using
a
bunch
of
other
features,
we're
gonna
have
to
make
a
copy
of
that
buffer
in
memory.
A
A
Obviously,
there's
other
ways
that
we
could.
The
key
thing
is
like
the
checksum
has
to
be
of
the
data
that
has
actually
written
sent
a
disk
and
making
the
copy
is
like
how
we
would
implement
that
twiddling
with
the
vm.
Subsystem
is
another
way
that
we
could
do
that,
but
right
now
we
think
that
would
be
slower
than
making
the
copy,
but
that
could
change
in
the
future.
A
Because
it's
in
the
car
all
right
because
luster
is
in
the
kernel
already
yeah,
so
we
can
just
say
like
well
the
kernel
like
if
you
use
this
particular
interface,
then
you're
guaranteeing
that
you
won't
change
it
and
that
interface
is
not
available.
You
know,
that's
not
what
we
use
for
the
right
system
called,
because
we
don't
know
that
a
user
mind
isn't
changing
it,
so
that
was
the
main
kind
of
like
change.
A
B
A
A
A
A
G
G
A
I
think
that's
definitely
an
area
where
we
like.
If
there's
a
good
reason,
we
could
definitely
change
that.
That's
not
like
a
hard
hard
requirement
on
our
side.
We
have
a
lot
of
wheelie
room,
wiggle
room
because
the
you
know
all
the
documentation
is
like.
If
it's
not,
if
it
doesn't
meet
some
alignment,
then
we
won't
do
it
and
we'll
give
you
an
error
so
in
a
bunch
of
other
file,
systems
chose
one
for
K
or
the
page
size.
B
So
the
other
thing
that
it
was
a
little
confusing
in
the
particularly
in
the
preamble
and
talking
about
the
motivations
it
mentions
a
lot
of
particularly
the
stuff
about
throughput
and
latency
of
write,
requests
and
stuff.
It
doesn't
really
feel
like
that's
borne
out
in
it
like
it
feels
like
the
classical
direct
justification
is
really
just
about
managing
your
own
buffers.
So
I
don't
know
that
it's
right
to
set
the
tone
necessarily
on
whether
like
huge
right,
latency
is,
is
acceptable
or
not
like
it
may
be,
but
I
don't.
B
It
really
feels
like
a
side
effect
of
the
justification
like
it
really
feels
like
oh
directors
for
Oracle,
my
sequel
and
stuff,
like
I'm
gonna
manage
my
own
giant
buffer,
cache
and
I.
Don't
want
the
double
caching
feels
like
really
came
from,
rather
than
being
about
increasing
throughput,
necessarily.
A
Yeah
I
mean
the
I
think
there's
two
questions.
One
is
kind
of
where
it
came
from
and
and
I
think
that
that
that's
definitely
true
and
I
think
the
other
thing
that's
key
about
where
it
came
from,
is
that
it
also
disables
POSIX
semantics
of
overlapping
rights
or
overlapping
operations,
because
POSIX
says
like,
if
you
have,
if
you're
doing
two
operations
like
a
right
and
any
other
operation
and
they
overlap
in
the
file
range,
then
they
happen
in
a
defined
order.
All.
A
Most
other
file
systems
implemented
that
by
saying
great,
each
file
has
a
reader/writer,
lock
and
so
like,
while
you're
doing
a
right
to
the
file,
you
can
not
do
anything
else
to
the
file
and
obviously
that's
horrible.
So
Oh
director
throws
that
up
just
as
like.
Well,
then,
we
won't
grab
the
lock
and
overlapping
reads
and
writes
like
have
like
who
knows
what'll
happen.
It's
your.
A
Doesn't
do
that
so?
Who
cares?
And
you
know
we
we,
we
are
not
throwing
investment
got
that
window
with
our
direct
because,
like
we've
had
range
based,
locking
from
day
one,
so
you
can
have
like
yeah
like
you
have
the
overlapping
things
are
ordered,
but
you
can
do
two
rights
to
two
different
offsets
concurrently,
so
I
wasn't
super
concerned
with
where
Oh
director
came
from
originally,
but
I
do
I.
Think
you
still
have
like
I
hear
your
point.
A
My
thought
was
like
if,
if
it's
really
about
buffer
management,
if
it's
really
about
like
I,
just
don't
want
this
to
be
double
cashed.
I,
like
I'm
telling
you
I'd
prefer
that
you
not
cash
this
because
I
don't
because
you're
just
gonna
be
wasting
memory
and
I
want
to
use
that
memory
for
other
stuff.
Then
a
much
simpler
implementation
is
possible,
which
is
like
kind
of
what
I
did
originally
when
I
was
prototyping.
This
so
like,
for
example,
for
writes
like
you,
don't
need
to
bypass
any
of
the
code.
A
You
can
just
say
like
do
what
we
always
already
always
did,
but
when
the
operation
is
done,
throw
it
out
of
the
cache
so
like
there's
no
reason
to
do
the
right
right
away.
We
just
do
do
buffered
style,
writes,
always
and
then
like
at
the
end
of
spa.
Sync,
we
notice
oh
like
this.
This
is
only
in
the
cache
because
of
it
was
a
direct
IRA,
so
we
just
evicted
from
the
arc
in
the
DM
you
and
whatnot
and
I
mean
I.
A
A
I
think
the
primary
consumers,
like
the
folks,
are
actually
doing
the
work
to
implement
this
like
Brian
and
Mark.
You
know
they
care
about
this
for
luster
and
other
kind
of
HPC
workloads
where
it's
not
I
mean
yeah.
The
buffer
management
is
nice
because,
like
they
don't
need
to
cache
it,
but
I
think
that,
like
an
equally
large,
if
not
larger,
consideration
is
that
they
want
to
maximize
throughput
and
minimize
the
per
byte
overheads
of
like
making
copies,
making
multiple
passes
over
the
data
and
all
that
stuff,
so
I
think
they're
concerned
with
that.
A
On
the
other
hand,
like
I,
I
and
probably
other
like
database
type,
users
are
more
concerned
with
the
per
block
overheads
of,
like
you
know,
instantiating
a
bunch
of
debuffs
and
a
bunch
of
other
stuff,
which
you
know
you
might
have
seen
like
from
my
work
with
sin
and
receive
recently
is
kind
of
all
about
minimizing
those
kind
of
overheads
and
I.
Think
that's.
If
you
take
the
principle
of
like
we
really
care
about
maximizing
throughput,
then
I
think
that
those
implementation
details
kind
of
flow,
more
naturally
from
that
than
if
we're
just.
B
A
B
And
so
from
that
I
think
I
I
do
think
we
should
consider
having
it
be.
The
current
behavior
today
should
still
be
the
default
behavior
and
that
you
should
turn
this
new
behavior
on
which
you
know
easily
the
people
doing
lustre
and
stuff
can
easily
like
yeah.
You
opt
into
this
because
they're
already
all
taken
into
presumably
a
bunch
of
other
stuff
as
well,
but
then
out
of
the
box
like
any
merely
by
rebooting
onto
this
update
your
application
that
makes
on
the
laundry
ice.
It's
not
gonna
break
basically
yeah.
B
B
A
D
A
Way
to
address
that
could
be
to
make
it
so
that,
like
unaligned
acts
like
no
unaligned
Oh
direct
like
there's
no
alignment
requirement
for
direct,
and
we
will
just
you
know,
do
it
like.
If
you
do
a
one-bite
unaligned,
read
then
like
all
right
sure
like
we'll
just
read
the
whole
thing
for
you
there
you
go
we'll
fix
it
in
post
production,
but.
B
B
We
could
do
that
and
any
other
then
yeah.
Oh
the
other
thing
too.
The
other
thing
that
it
does
feel
like
a
breaking
change
is
pools
with
no
redundancy
and
no
encryption
and
no
compression
I
guess
you
have
had
to
turn
the
check
sums
off
right
to
get
the
the
where
the
buffers
can
be
twiddle
during
the
rock.
A
B
B
What
I
remember
from
some
of
the
encryption
work
that
went
on
for
a
really
long
time,
some
of
the
last
things
that
we
chase
down
what
were
like?
Not
the
encryption,
decryption
and
stuff,
not
necessarily
always
happening
at
all
the
places
that
it
needed
to
happen
in
the
pipeline's,
because
the
abstractions
didn't,
but
there
wasn't
necessarily
one
clearinghouse
for
for
where,
where
that's
those
specific
decisions
needed
to
be
made
around
some
of
the
new
flags.
Is
there
it's
the
implementation
of
this?
Where
we're
making
that
decision?
Whether
the
buffer
unlocked
read,
can
happen
or
not?
B
A
I
would
think
so
because
the
I
think
the
issues
that
you're
talking
about
are
with
like
when
you're
dealing
with
an
encrypted
data
set.
Sometimes
you
don't
need
to
decrypt
it,
and
sometimes
you
do,
and
that
is
that's
where
the
trickiness
came
in
versus
in
this
case
like
if
encryption
is
enabled
on
the
data
set,
then
you
do
not
get
this
SuperDuper
fast
path.
Behavior
and
the
encryption
can't
be
like
you
know.
That
said
at
creation
time
and
does
not
change
so
I.
Think
that's
fine,
but.
A
A
The
direct
operations
I
have
poor
alignment,
is
that
applications
might
be
doing
doing
direct
operations
and
then
like
checking
to
see
if
they
worked
or
not,
and
if
they
didn't
work,
then
like
increasing
the
the
size
of
the
dream
or,
like
you
know
otherwise
modifying
their
behavior
to
be
more
optimal
so
like
telling
them
like
hey
you
try
you,
you
tried
to
do
this
I
can't
like
I,
can't
really
do
it
fast.
The
way
that
you're
asking
me
to
so
hit,
try
again
like
try
something
else.
I'm.
B
A
A
A
G
A
A
Yeah
I
apologize
folks
we're
out
of
time.
There
were
a
few
things
that
we
want
yeah
updates
on
and
then
also
calls
out
for
code
reviews,
I'm
just
going
to
say
what
those
were
and
then
we'll
we'll
discuss
them.
Next
time-
and
please
add
I'll-
add
this
on
the
slack
channel
as
well,
so
the
status
updates,
josh
Petzl,
already
posted
a
status
update
on
the
Penn
zero
debut
its
they
haven't,
made
much
progress,
but
they
still
want
to
alan.
A
Has
the
status
update
on
DD
blog
and
the
DDT
limit
and
I
saw
that
he
just
opened.
Perhaps
during
this
meeting
a
pull
request
on
the
YouTube
limit
or
any
duper
ceiling,
there
are
also
pull
requests
out
that
need
reviews
on
persistent
l2,
r,
k--
z,
standard
compression
and
the
d
duple
ode,
which
is
like
a
prefetch
or
like
please
go
read
in
the
d:
do
from
youtube
table
from
disk
synchronously,
so
people
who
are
in
a
position
to
review
that
code.