That's not contrary to what I'm saying which is that RAIDZ is slower than non-RAIDZ.
How many times do I have to repeat this?
Insanity is doing the same thing, over and over again, but expecting different results.— Albert Einstein
Everyone is entitled to his own opinion, but not his own facts.— Daniel Moynihan
You could do with supplying some facts. It'd probably make a difference.
Which is to say that RAIDZ will also be slower in terms of raw bandwidth than is available than ZFS with mirroring or striping.
Roch writes in the blog comments himself:
For Streaming purposes RAID-Z performance will be on par with anything else.Further Jeff Bonwick, who was ZFS engineering lead, writes in the blog comments and also on the
zfs-discuss@opensolaris list:
It's only when you're doing small random reads that the difference between RAID-Z and mirroring becomes significant. For such workloads, everything that Roch said is spot on.Petabyte storage from Aberdeen says
its ideal configuration is RAID-Z2 in each of the eight JBODs, with the octet pooled together.[1] Somehow I doubt they'd choose their ideal configuration to be "
terrible for performance."
That's because RAID 5 isn't RAIDZ and thus discussion of it (RAID 5) is not relevant in a discussion thread on RAIDZ except to serve as a distraction and a destination for more rat-holing.
The original poster mentioned his RAID 5 array in post #1. In my post #25, I compared RAIDZ and RAID 5, making RAID 5 the original context in which RAIDZ was brought up.
RAID 5 is block level striping with single parity. RAIDZ is dynamic striping with single parity. RAIDZ is routinely compared to RAID 5, including the earlier Aberdeen example, and the authors of this book on ZFS:
In ZFS you can also create redundant vdevs similar to RAID-5, called RAID-Z.Quote from
Solaris 10 ZFS EssentialsBut to take this a step further, unless you're streaming video content or working with really large files (100s of megabytes in size) then random IO is the correct model to use for determining whether something is good or bad. It's definitely the right model to use for any disk that has images on it.
whiskey tango foxtrot, this must be a joke. Who wants to let me in on it?
Now, after 60 posts, you redefine what "small random IO" is in order to make your past ridiculous arguments somehow correct? Fine, but in so doing, you're essentially saying 99% of all data on the planet is small random IO. Which is equally absurd.
After reading dreed's post, I feel like I've just watched an episode of
Charlie the Unicorn Goes to Candy Mountain.All Tom's Hardware tests use a 4KB block size for random IO tests. I found
one test with 4K and 512KB. No bigger. The default NTFS and JHFS+ allocation block (or cluster) size is 4K. For RAID 0 and 1 it's typically 128KB.
And the fragmentation for some randomly chosen files on my computer:
7MB DNG 1 extent
25MB DNG 1 extent
62MB 8bpc TIFF 3 extents
126MB 16bpc TIFF 3 extents
788MB 16bpc TIFF 9 extents
Considering the worst case scenario, including if Apple and Microsoft weren't doing any optimizations to avoid fragmentation, that 7MB DNG could be made of 14,336 fragments, i.e. one per disk sector, with zero contiguous sectors. Our file systems are, fortunately, engineered to be more efficient than this.
None of the example files, or any of the other dozens I've looked at, does random IO apply. It is overwhelmingly sequential IO because disk seeks are not appreciable, let alone dominate.
The most pertinent message on that topic has been the desire for external disks to perform at the same speed as internal disks. That will mean both IOPS and bandwidth. What they are interested in is connecting an internal disk to their system and getting similar performance to their internal disks. For me, that says they want eSATA, USB 3.0 or better.
People get similar performance with images on FW800 external disks, compared to SSD. Ian called the difference "negligible". That bodes well for storing Raw/DNG on GigE.
Working through already rendered images quickly in Library, will pull JPEG previews from whatever storage you have the catalog (lrcat and lrdata) on. And Develop previews come from the Camera Raw cache. Both of those should go on your fastest disk regardless of whether it's internal or external.
ok, so now you've resorted to insults.
Bunk means nonsense. It was an observation.
I'm not thinking you're a moron. I'm thinking that you think everyone else is a moron. Or, again, it's a joke. Either way, in my opinion, it is you who are being insulting.
[1]
What Does One Petabyte Of Storage (And $500K) Look Like?, page 6.
