Hello Bart,
Thanks for the answers...
Bart Smaalders wrote:
Clearly, there are elements of the model that don't apply to our
sustained read/writes, so does anyone have any guidance (theoretical
or empirical) on what we could expect in that arena?
I've seen some references to a different ZFS mode of operation for
sustained and/or contiguous transfers. What should I know about them?
What you need to know is what part of your workload is
random reads. This will directly determine the number
of spindles required. Otherwise, if your workload is
sequential reads or writes, you can pretty much just use
an average value for disk throughput.... with your drives
and adequate CPU, you'll have absolutely no problems
_melting_ a 1GB net. You want to think about how many
disk failures you want to handle before things go south...
there's always a tension between reliability and storage
and performance.
Absolutely. I've been thinking about that a fair bit (strongly aided by
blogs.sun.com and the list archives). This server is for research
purposes, so it will be tested with various workflows at different
times, but most will be streaming IO. The most demanding imagined is
that real-time uncompressed HD write.
And as it'll be for research, popping in and out of different scenarios,
long-life reliability isn't a major issue. Some resilience is always
helpful to help offset my "cheap" criteria.
Consider 2 striped sets of raidz2 drives - w/ 6+2 drives in each
set, you get 12 drives worth of streaming IO (read or write).
That will be about 500 MB/sec, rather more than you can get
though a 1 GB net. That's the aggregate bandwidth; you should
be able to both sink and source data at 1Gb/sec w/o any difficulties
at all.
If you do a lot of random reads, however, that config will
behave like 2 disks in terms of IOPs. To do lots of IOPs,
you want to be striped across lots of 2 disk mirror pairs.
My guess is if you're doing video, you're doing lots of
streaming IO (eg you may be reading 20 files at once, but
those files are all being read sequentially). If that's
the case, ZFS can do lots of clever prefetching.... on
the write side, ZFS due to its COW behavior will just
handle both random and sequentially writes pretty
much the same way.
Okay, the way you say it, it sounds like a good thing. I misunderstood
the performance ramifications of COW and ZFS's opportunistic write
locations, and came up with much more pessimistic guess that it would
approach random writes. As it is, I have upper (number of data spindles)
and lower (number of disk sets) bounds to deal with. I suppose the
available caching memory is what controls the resilience to the demands
of random reads?
Thanks,
adam
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
