[mythtv-users] Where are those new 1TB drives?

Brock Palen brockp at michiganlivestock.com
Mon Mar 12 16:41:29 UTC 2007

On Mar 12, 2007, at 12:28 PM, jedi at mishnet.org wrote:

>> On Monday 12 March 2007 15:14, jedi at mishnet.org wrote:
>>>     That's a very dangerous assumption. It's rediculously easy to
>>> overwhelm the RAM cache on even the most expensive SAN hardware.
>> That's what I also thought untill I did some serious stress tests.
>> I changed read/write ratios, random I/O, sequential I/O, number of
>> threads, ...  The differences between raid 5 and raid 10 was max  
>> 5%.....
> IOW, you did a "benchmark".
> You created an artificial situation specifically designed to create
> a working set that can fit into whatever cache happens to be under
> discussion: cpu, hba, san.

Very true,  my day job is a Super Cluster (HPC) administrator for a  
University.  We have a system which consists of 21TB of spinning disk  
of which our portion (that we send to the cluster) is 6TB used in  
raid 6  (why don't know)  But the data movers have 6GB of cache, and  
yes we found big differences once you get outsize that cache.  raid 5  
and 6 bad bad bad for some cases,  raid 3 and 10 worked better in  
some.  I dont have the data close by but for our work (real random  
research) nothing did everything nice.

> That still doesn't have any real relevance to real world workloads.

See the above. :-)
> This is why the people that run the companies that sell the sort of
> highend gear you're speaking of still recommend SCSI over SATA for
> it's better command queuing.

True, kinda, because of all the cache,  we shut off all drive  
features (cache and CQ)  And let the raid cabinet and and data movers  
to be smart (and they are).  This is because we are using SATA drives  
and the problem with drives lying about data being being written to  
disk.  Talk to anyone who built a DB system and they will rant up a  
storm about drives giving bad sync states back.

> Plus an extra 5% can be very relevant for some applications.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

More information about the mythtv-users mailing list