VTrak E+J - 200/332 MB/second Read/Write - Public Metadata
What do you think of 200MB/s Write and 332MB/s Read for an E+J setup? Do you think I can do better?
ALL the dirty details are here below. Please let me know any Command Line Programs or other techniques I can try to test and improve things.
• dedicated MDN is on the way,
• is the "dd" command line program appropriate to test with?
* * *
I am working through things with the IT department at the place I work at and am awaiting the installation of a Cisco 1000BT switch for Metadata, but in the meantime, I have installed the Xsan using the 10/100BT public network for Metadata.
We are running two ethernet connections from each MDC and Client.
All IP's are static.
i.e. eth00 Public = 172.x.x.50, eth01 MD = 172.x.x.51, ect.
All Macs have two 4GB Fiber connections (4 strands total).
Vtrak E controller has latest firmware and all four FC ports connected with 4GB copper Apple cables.
All plugged into a SanBox 5600 and showing up as 4GB.
Bullet Proof Zoning and RSCN suppression is on, Device scan on (based on recent discussion that it doesn't hurt.)
VTrak E+J configured using Apple KB / Promise recommended configuration script:
All disks are 750GB SATA.
DATA 1 through DATA 4 are 6 disk RAID 5's grouped into the Main VIDEO Pool.
In Xsan Admin I setup two Folders in the Root of the Xsan Volume:
"Capture and Footage" - Affinity Tagged to the Data1 through Data4 VIDEO Pool.
"Not Video" - Affinity Tagged to the SCRATCH Pool.
I believe I left the Xsan Volume Block Allocation Size at 16KB and Round Robin.
But I set the Stripe Breadth for the VIDEO Pool to 256K
I had previously tested the default (32k?), 64k and decided to skip 128k for now. But for those previous tests, I had only used AJA System Test and the old Xsan Tuner.
But yesterday, I saw Xsanity Forum member Lotte's post containing the following Command Line Program:
dd if=/dev/zero of=/PATH/TO/YOUR/VOLUME/testfile bs=8192k count=1000
(sends 8MB 1000 times to make an 8GB file)
dd of=/dev/null if=/PATH/TO/YOUR/VOLUME/testfile bs=8192k count=1000
(reads back that file, but only after you write it)
So today I tested my Volume using those commands.
Running the programs from my Mac Pro Client02 produced:
113436622 bytes/sec (108 MegaBytes/sec) when Writing
to the Root level of the Xsan Volume.
159238744 bytes/sec (151 MegaBytes/sec) when Reading back.
210502792 bytes/sec (200 MB/s) when Writing
to the Affinity'ed "Capture and Footage" folder.
349120310 bytes/sec (332 MB/s) when Reading back.
114347325 bytes/sec (109 MB/s) when Writing
to the Affinity'ed "Not Video" folder.
159348495 bytes/sec (151 MB/s) when Reading back.
* * *
Based on these numbers, I think the root level of the disk and the SCRATCH Pool are the same place. Hmm...
Do Affinity Tags PREVENT non tagged data from being written to a LUN in a Tagged Pool or do to they ONLY ENSURE that Tagged Data is Routed to the matching LUN? Hmm...