Chris Murphy
Forum Replies Created
-
Perhaps I’m missing something. I’m only seeing GigE Presto PCIe cards. i find it rather clunky to put have to buy a PCIe expansion chassis, and put in a 10GigE PCIe card, in order to get 10GigE on a Thunderbolt only MacPro. So what I’m curious about is a 10GigE version of Apple’s existing GigE adapter, either from Apple or a 3rd party.
-
I’m vaguely curious about how 10GigE support is going to play out.
-
It seems to me Canon is lagging on two fronts: Using CompactFlash where XQD is indicated, and then somehow getting CF to perform worse than SD when CF is ancient and inferior in every way compared to SD. CF is expensive to buy, and much more prone to causing bent pins in the camera which is also expensive.
-
The original statement mentioned array size as the factor determining performance, rather than number of disks, and it also didn’t distinguish between reads and writes. It’s true that there is a raid5 write penalty that is most noticeable with fewer disks.
Both slow reads and writes indicates full stripe reads aren’t happening which points to too large chunk size for the test; or conversely the test is making many small IO requests that the raid has to do large reads, discarding most of the data to fulfill the request. So it’s a mismatch between test and configuration. Either the configuration is wrong or the test is wrong. Without detailed information on the configuration, the tests, and the real world usage, it’s not possible to categorically say the tested performance won’t meet real world requirements.
-
For chunk size, the goal is to maximize full stripe writes. Full stripe is chunk size * number of data disks. To find chunk size you need to look for a chunk or stripe size value in your raid software. And you need to know something about your typical write sizes, to figure out chunk size. A too high chunk size gets hit with RWM penalty at the raid chunk level. Too small chunk size means the disks become excessively bound in IO which also hurts performance.
Another factor is the HFSJ/HFSX journal. It’s 8MB per 100GB of file system up to 512MB. So you have a 512MB journal which is quite large. It might be worth disabling the journal and redoing your tests to see if there’s any change. Ultimately you want the journal on to avoid either long fsck times in the event of a crash, or not doing fsck at all in which case it’s a matter of not much time before the file system trashes itself. It can be temporarily disabled through the diskutil command. If performance picsk up dramatically then you probably have moderate to heavy metadata writes, and to fix this longer term either reduce the chunk size, or relocate the journal to an SSD, which is supported but not in the GUI.
Another source of RWM performance hit is when the raid chunks aren’t aligned to a drive’s physical sectors. This ought to not happen these days. But it depends on if the disks are partitioned or not and what partitioned them and if it does so correctly. This is not the same thing as partitioning the resulting array that appears in Disk Utility. The raid manufacturer should be able to tell you this.
-
If it’s the HUS724040ALE640 then I think there is more than one thing going on that’s not right, because those drives should do ~180MB each, so striped reads should draw a lot more than 250MB/s depending on the specifics of the configuration. The write speed could either be low for the same reason the read is, which is an chunk size that’s not appropriate for the workload; or it could be excessive RWM due to misalignment, as these drives are 512e AF disks.
So more information is needed. Exact model number. What’s the raid card. What’s the chunk and/or stripe size. How many disks. What is the work load (how big are the files being copied when the 95/250 benchmark is determined.)
-
I can’t speak to the compatibility of these combinations. But I’d make sure you test it, including pulling a drive and making sure it actually rebuilds. And don’t forget to do periodic scrubs.
-
I’m not really understanding this. You are presently using two G-Speed eS, and the RAID card is the G-Technology HighPoint Rocket SATA 3Gbps 4-Port PCI Express x4 eSATA RAID Controller? You want to put that card into a Thunderbolt->PCIe enclosure so you can continue to run the existing RAID5 array? I think you need to ask G-Technology what they think of this. I’d like to think it’ll work.
But then you’re asking about other RAID cards than the one you apparently have already and I don’t understand that part. Realize that every RAID implementation is different, the metadata written to disk and the layout can even be different. They’re not inherently mutually compatible. There is an SNIA defined format called DDF (Disk Data Format) that some manufacturers may be using, namely LSI. I don’t know if either card you have or want to use are supporting DDF. And even if they do both support DDF, there are a lot of ways they can differ so I’d just be really cautious – make sure the backup is recent before you begin.
-
I see this cross posted here.
I don’t expect file system corruption when reading data from the card, but is it formatted exFAT or FAT32? exFAT is less resilient than FAT32 since it doesn’t have dual FATs.
-
It’s more correct to say that Thunderbolt is a derivative that combines PCIe and DisplayPort protocols onto a single physical transport. I’m not suggesting a bandwidth equivalence. However a Thunderbolt connected storage device is effectively on a PCIe bus, just as is any SATA add-on card that plugs into a standard PCIe slot. As for crashes, that doesn’t make it “not PCIe” it just means it’s subject to driver and firmware bugs.
In any case, the application use of a disk for scratch space is creating a file via OS level APIs. The application has no idea what the underlying hardware is, what sort of bus it’s on, nor even if it’s rotating or non-rotating media.