►
From YouTube: ViennaScientificCluster
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
I'm
gonna
run
through
is
we've
looked
at
and
I'm
gonna
show
who
we
are
just
a
second
we've
looked
at
the
performance
of
using
using
the
the
zfs
as
as
a
store
for
a
parallel
file
system
on
top,
and
we
use
the
fraunhofer
parallel
file
system
generally
familiar
with
it.
So
I'm
gonna
spend
a
few
words
on
it,
charlie.
A
So,
first
looking
at
the
use
cases
there's
a
big
disclaimer.
I
should
actually
both
type
it
some
performance
data
we
we
retrieved
and
some
some
going
forward
now
we're
in
hpc
center.
So
we
do
high
performance
computing.
We
do
that
for
for
science
users
in
multiple
austrian
universities,
we've
got
one
can
already
say
three
clusters,
because
this
is,
as
you
see
is
from
yesterday.
That's
a
matter
of
fact.
The
third
one
is
being
built
as
we
speak.
A
We
mostly
have
hpc
standard
hpc
codes,
so
that
codes
for
weather
weather
forecasting
and
there
are
codes
for
various
physics,
applications,
finite
element,
analysis
and
so
on,
and
they
usually
run
as
a
message
passing
over
mpi,
and
this
is
infiniband
connected
nodes.
So
that's
basically
the
environment
for
for
the
point
of
node.
In
here,
for
just
for
the
environment,
this
will
be
the
largest
oil
cooled.
A
This
is
this:
is
an
oil
pump
hpc
site
in
europe
very
shortly,
so
this
is
actual
actual
boards
being
being
put
into
oil.
So
this
is.
This
is
something
with
some
novelty
value
now.
A
The
the
use
cases
we
look
at
here
for
for
cfs
is,
is
scoped
to
be
around
archiving
around
user
data,
backup
and
there's
some
priorities
in
in
terms
of
what
we
look
at-
and
this
is
not
necessarily
the
the
the
weighted
list,
but
the
reliability
is
is
really
really
much
on
top
performance
is
not
in
this.
In
this,
with
these
use
case
is
not
really
the
the
top
one
at
all.
So
we
we
look
at.
A
A
For
the
parallel
file
system
called
fraunhofer,
a
global
file
system
hgfs
as
it
used
to
be
called,
and
now
it's
called
bfs
a
big
there's,
a
b
symbol,
apparently,
which
now
comes
with
it,
so
we're
using
a
parallel
file
system
coming
from
the
quote-unquote
makers
of
mp3-
and
this
is
a
file
system
which
you
can
think
of
separate
separate
storage
nodes,
separate
metadata
nodes
made
to
really
allow
for
multi
gigabyte
throughput
for
for
users
such
as
genomics
and
and
what
comes
so
this
this
scales
to
very
large
40,
50,
60,
70
80,
and
this
the
curve.
A
The
curve
is
very,
very,
very,
very
nice.
So
this
is
a
a
very
high
performance
file
system.
So
the
the
questions
we
looked
at
first
and
I
I'll
say
it
very
openly-
we
were
quite
negative
on
it.
So
we're
looking
at
this.
Is
this
stable,
zero?
Six
two
for,
for
our
purposes,
is
the
stack
stable,
is
it
performing
and
so
that
the
null
hypothesis
were
actually
no.
B
A
Just
look
at
it
as
an
exploratory
testing
now
disclaimer
for
for
for
the
data
is
and
you're
gonna
see.
We
we
thoroughly
rejected
this
sort
of
hypothesis.
It
turned
out
to
be
extremely
doing
extremely
well.
Actually.
For
most
part,
the
the
disclaimer
is,
of
course
these
are.
This
is
work
in
progress.
Non-Finished,
it's
just
a
snapshot,
it's
mostly
synthetic
workloads,
so
just
one
is
one
is
called
a
real
world,
a
real
workload.
And
last
but
not
least,
it's
not
optimized.
That's
for
sure.
A
So,
there's
a
long
list
of
optimizations,
which
can
be
can
be
tried
as
we
go
now
free
environments.
One
is
a.
These
are
not
huge
environments
for
this
testing.
One
is
one
one
blown
up
server
node
with
a
collapsed
metadata
management
management
with
another
management
tool
on
it.
Then
then,
two
to
infinite
bands
most
for
those
tests.
A
We
only
use
one
though
we
have
enterprise
ssds
in
there
for
for
for,
for
the
for
the
cache
and
from
the
l2arkan.com,
then
we
do
have
eight
load,
creating
clients
for
this
environment
and
release
wise
again,
it's
shown
before
second
environment
is
from
from
prior
cluster.
Just
for
for
sizing
sizing
up
the
testing,
it's
for
old
sunfire
nodes,
which
you
see
here
no
surprises
here.
The
next
environment
is,
is
a
server
node
out
of
another
cluster
which
is
amd
here.
A
Yes,
this
is
built
on
raid
for
for
for
process
reasons
and
going
forward,
we'll
we'll
put
we'll
we'll
put
it
on
on
jbod,
of
course,
and,
however,
we
we
we
we
had
this
on
on
the
on
the
on
the
rate,
the
the
the
first
battery
of
tests
were
basically
looking
at
the
com
garage,
combinations
of
native
file
system
we
use
xfs
sort
of
is
the
default
default
native
and
zfs
and
remote,
not
remote,
and
so.
B
A
A
Basically,
what
to
see
from
that
is
the
the
the
small.
I
would
disregard
that
the
small,
the
small
file
sizes.
We
were
just
seeing
early
on
that
that,
of
course,
cache
isn't
so
matter,
but
what
matters
is
that
the
large
number
of
files,
this
performance
everywhere
is
just
bad
and,
however,
it's
along
the
lines
of
the
other
options,
so
cfs
being
one
and
the
others
being
similarly,
not
not
too
high,
but
it's
not
grossly
grossly
off.
A
So
this
is
a
first
first
string
to
to
see
and
then,
as
we
go
to
the
larger
file
sizes,
the
the
data
becomes
more
interesting.
So
I
would
go
straight
to
here:
there's
a
eight
something:
almost
a
terabyte
file,
ballpark
wise,
where
we're
we're
comparing
compe
we're
getting
into
the
region
of
native
xfs
and
there's
some
some,
some
of
course
local
remote
differences,
but
ballpark
wise.
A
We're
we're
coming
close,
then,
here
here
a
a
another
baseline
test,
where
we
put
the
the
only
the
xfs
is
as
backstore
and
here-
and
this
is-
this
is
a
key
figure
for
us
per
node
this.
This
shows
about
3.6
gigabyte
per
second,
so
this
is
a
again
disclaimed
in
here.
This
is
this
is
one
way
to
measure
it.
Otherwise,
you
get
you
get
different
values,
but
this
is
close
to
native
performance.
What
over
infiniband
qdr
what
you
can
get,
so
this
is
actually
the
three
six.
A
This
might
have
some
cache
effect
in
there.
This
is
this
is
very
high.
The
here
we
have
a
red
z
already
with
four
tanks
with
nine
discs,
and
there
comes
already
the
surprise.
So
again,
we
were
very
negatively
looking
at
this
at
first.
So
how
can
this
and
so
on
in
this
deck?
A
But
here
here
we're
reaching-
and
this
is
without
any
optimization
at
all-
are
reaching
about
two
points:
2.7
gig,
2.2
gig
in
this
in
this
configuration,
which
is
pretty
good,
it's
pretty
good,
very
good.
Actually
so
this
is
this
is
this.
Is
this?
Is
a
a
territory
we're
we're
in?
And
this
is
definitely
something
in
in
the
in
the
sort
of
admissible
range.
A
A
And
then
here
or
what
the
parameters
are
different,
then
here
it
it
even
goes
up
to
a
three
three
point:
four
f2.
If
they
look
for
the
test
parameters,
I
don't
have
them
on
the
slide.
A
I'm
trying
to
figure
out
what's
the
difference
between
those
two
words,
I
cannot
see
it
on
the
slide,
so
I'm
afraid
I
have
to
go
back
to
the
notes.
So
there
must
have
been
a
different
parameter.
I
I
would
have
to
go
back
to
the
note,
so
there's
some
parameter
different.
Obviously
the
reading
goes
up
to
3.4.
I
would
believe
I
would
believe.
No,
I
couldn't
say
I
have
to
go
back
here
here
then
there's
a
stripe
of
four
four
four
four
times:
eight
again
nested.
A
Nested
and
here
with
different
file
sizes-
and
you
can
see
two
four
up
to
64
clients
leading
to
leading
to
about
on
the
on
the
large
file,
says
again:
2.3
geeks,
which
is
which
is
which
is
excellent,
which
is
excellent
in
here,
just
just
marvelous.
So
this
is
this:
the
real
real
world
fraunhofer
file
system,
layered
on
top
of
the
the
nested
raid
z1
2.3,
with
a
with
a
single
server.
Perfect
here,
is
another
test.
We
used
the
the
benchmark
tool
called
ior.
A
We
like
to
use
this
for
for
mpi,
especially
if
multiple
different
processes
are
active
here
is
a
simple
single
single
case,
but
this
tends
to
lead
to
lower
lower
values
in
comparison
with
with
other,
simpler
tests.
But
this
is
also
a
very
good
figure
in
here.
One
one,
gig
very
good
figure.
A
Here
it
becomes
a
little
bit
more
difficult
now,
so
here's
some
read
write
a
hundred
thousand
files.
The
the
the
the
performance,
as
shown
before,
is
pretty
comparably
bad.
As
for
for
other
file
systems
or
the
layered
file
systems.
However,
the
the
the
let
me
go,
the
in
the
in
the
following.
A
Now,
last
but
not
least,
we
did
some
do
not
show
that
data
here,
because
it's
it's,
it's
almost
un,
it's
too
good
to
be
true,
so
we
have
to
go
back
to
to
to
to
doing
more
measurements,
but
we
did
like
a
72
disc
stripe
with
all
all
out
load
on
on
this
on
this
stripe
and
we're
we're
basically
getting
infiniband
speed
on
it.
So,
despite
the
layer,
despite
despite
with
huge
files,
it's
it's
very
good.
It's
very
good
now
comes
the,
however.
A
A
The
the
the
l2
arg
and
zil
were
were,
of
course,
their
enterprise
ssds.
Now
here's
the
good
part,
the
compression
we're
getting.
Is
nice
and
1.5
approximately
this
this
this
pace
now
with
dtap,
enabled,
I
shall
say
in
the
dub,
not
all
files
as
of
measure
as
of
measuring
this,
not
all
files
have
actually
been
been
on
the
dtop
now.
As
of
measuring
this,
the
the
the
small
file
is.
This
performance
is
metadata.
A
Side
is
really
really
an
issue,
so
we,
if
you,
if
you
traverse
for
152
million
files
with
a
recursive,
ls
or
a
concretely,
I
think,
a
find,
find
not
minus
x
just
defined
recursively
through
through
the
tree,
looking
at
like
10
hours
or
so,
and
if
you
do
a
find,
and
if
stat
and
so
on,
on
the
files
it
gets
even
worse.
So
this
is.
A
This
is
quite
quite
long
so
here
here,
however,
in
this
test,
with
the
with
the
with
the
long
long
recursive
runs,
this
was
just
cfs
and
not
layered
on
top,
so
presumably
this
would
not
get
better
with
it.
Maybe
so
here
here
there's
room
of
room
for
improvement,
so
this
is
really
difficult,
yeah,
so.
A
This
was
this
was
with.
Let
me
think
this
is.
A
C
We
have
the
hardware
rate
I
have.
A
I
have
to
have
to
look
in
there
what
the
data
is.
I'm
sorry
I'll
follow
up
right,
yeah.
C
Right
now
and
but
you
did
have,
but
you
were
using
deduplication,
it's
really
giving
you
any
benefit
in
this
early.
A
To
call
this
is
so
large,
it
takes.
It
takes
so
long
to
the
if
the
copy
this
over
and
so
more
more
data
is
coming,
but
so
far
it's
not
it's
not
bringing
that
that
much
of
a
benefit
so
metadata.
This
is
this
is
this
is
this?
Is
this
is
an
issue,
however
running
these
things?
I
mean
think
of
it.
This
is
152
million
files.
This
is
many
many
a
double
digit
terabyte,
so
that
this
runs
out
of
the
bed.
Unoptimized
stacking
this
on
each
other.
A
This
is
this
is
this
is
very
nice,
and
this
is
well
well
be
above
expectation,
so,
even
even
under
many
many
file
sizes
this
this
could
this
could
basically
do
it.
So
we
we
saw
a
very
few
issues
if
at
all-
and
one
is
that
this
is
not
this
is
this
is
a
non-issue.
A
This
is
not
an
issuer
bug
where
we
just
ran
into
this
from
the
very
beginning
that
the
udev,
the
linux,
udev
messes
things
up,
tiny,
tiny,
tiny,
something
we
think
we
saw
a
memory
leak
on
the
on
the
user
data
backup
site.
This
is
now
instrumented,
not
the
d
trace
or
anything
just
looking
at
the
memory
as
it
goes
along
and
see
if
you
can
reproduce
it
and
the
key.
The
key
thing
is
that
one
would
have
expected
layer
this
and
non-si.
No,
no
side
has
really
adapted
anything.
A
So
what?
What
would?
What
would
be
of
interest
going
forward
from
from
from
from
our
perspective
of
operating?
These
things
is,
is,
is
checksums
end-to-end,
of
course,
not
computing
them
multiple
times.
So
that's
one
thing,
erasure
codes.
Oh,
we
would
love
this
so
if
he
could
do
away
with
raid
and
have
this
all
in
the
in
the
distributed
file
system,
the
parity
information
and
then
all
scattered
around
the
disks.
This
would
be
very,
very
nice
indeed.
So
this
is
not
a
cfs
issue.
A
A
Let
me
let
me
let
me
in
comparison
without
rate
c,
just
non
non-cfs
we
did,
but
without
raid
c
I
have
to
go
back
to
the
data
I
I
will
come
right
back
after
the
the
presentation
here,
acknowledgements
and
so
again
this
was
a
snapshot
of
measurements,
so
far
very
happy
against
low
expectations,
but
very
happy
we'll
we'll
go
on
testing.
A
We
haven't
done
this
yet,
but
we
will
be
doing,
is
bit
rot
testing,
so
I'm
I'm
writing
a
little
little
little
tool
there
to
to
selectively
flip
bits.
Put
it
up
then,
and
we
need
to
do
more
negative
testing.
So
we
have
done
negative
testing.
It's
not
listed
here
in
the
slides,
but
yes,
we
have
done
it,
pull
the
disc
pull
the
cord
and
because
reliability
is
most
important
first
and
it
always
came
back
always
came
back.
A
So
the
most
important
is
that
the
feeling
that
you
would
trust
this
to
be
reliable
is
actually
so
far
so
good.
But
again
we
need
to
do
more
much
more
negative
testing
for
that.
We
need
more
test
automation,
so
we've
written
some
scripts,
and
so
but
this
needs
more
of
it.
That's
it.
A
I
couldn't
I
couldn't
say
I
I
I
couldn't
say
that
that
the
s
is
status,
but
I
believe
well,
first
of
all,
I
we're
a
commercial
user
of
it,
but
I
believe
the
base
use
of
it
is
free.
I
believe,
and
the
client
side
I
believe,
is
open
source
and
as
a
commercial
user,
we
can
get
the
source
of
the
server
but
which
is
not
open
source.
I
believe,
but
the
base
usage
without
any
support
contractor
so
is
is
free.
As
far
as
I
understand,
yeah.
B
Thanks
so
on
the
scenario
you
presented,
that
you
used
raid
hardware
right.
A
Right
this
again
will
not.
We
will
not
use
this
rate
going
forward,
but
for
I
should
say
in
operations,
you
go
step
by
step
and
things
you
know
very
well.
You
know
rate
and.
B
C
Yeah,
I
mean
performance
wise,
it's
not
necessarily
a
clear-cut
case
because
it
depends
on
like
what
hardware
is
in
that
raid.
So,
like
you
know,
raid
z,
obviously
like
raid
z,
has
its
own
performance
issues
and
if
you
have
you
know
a
beefy
piece
of
hardware
raid,
that
has
you
know
some
nvram,
that's
caching
and
you
know
it
could
actually
accelerate
performance.
It's
just
that
you're
spending
a
lot
of
money
on
that
right,
so
cost
performance,
yeah
you're,
definitely
gonna
do
better
with
with
just
zfs
on
raw
discs,
but
ultimate
performance.
A
Think
of
it
also
as
a
question
of
operation
things,
so
we've
got
many
many
disks,
so
we
know
we
have
procedures
when
a
disk
fails
and
with
cfs
all
this
has
to
be
established
first.
So
this
is
how
we
went
yep.
Okay,.