[Info-vax] analyze/disk errors

[tadamsmar]

On Friday, February 7, 2014 10:59:24 AM UTC-5, Stephen Hoffman wrote:
> On 2014-02-07 15:01:37 +0000, tadamsmar said:
> 
> 
> 
> > ...in addtion to being available new, the 15K RPM would (I think) speed 
> 
> > up system response.
> 
> 
> 
> TL;DR: "It depends".
> 
> 
> 
> Tuning is an iterative process, and based on data; on finding and 
> 
> improving or replacing or tweaking the slowest component.
> 
> 
> 
> For instance, maxing out memory can often be an easier and cheaper win, 
> 
> as it can increase the (read) cache hit rates and reduces the I/O 
> 
> rates, and can (if enabled) reduce write rates with the (optional) 
> 
> write caching that can be performed by RMS.
> 
> 
> 
> Check the seek times and the transfer rates in the specs, not the RPMs, 
> 
> and check the I/O activity and queue depth, and see if you're pushing 
> 
> the I/O hard.  Faster seeks are better for smaller transfers and for 
> 
> fragmented storage, and higher-RPM disks are better for larger-sized 
> 
> transfers.
> 
> 
> 
> Switching to SSD and to host cache are usually much better than hitting 
> 
> any rotating rust.  Switching to larger I/Os and away from record 
> 
> access can be a win, too.
> 
> 
> 
> This performance and tuning stuff can rathole pretty easily, too.  For 
> 
> some I/O activity patterns, a slower disk with a bigger disk cache will 
> 
> beat a faster disk, for instance.
> 
> 
> 
> IIRC, the boxes involved are fossil-grade systems, and would have to be 
> 
> running fairly close to their respective I/O performance limits to see 
> 
> a wall-clock-relevant difference here between a 10K disk with decent 
> 
> seek times and a 15K disk with a similar seek time.  It's certainly 
> 
> possible you might see an improvement, but I wouldn't automatically 
> 
> assume it.  And I wouldn't buy something extra that's not going to be a 
> 
> benefit.  Wall clock relevant?  Even if the systems are close to their 
> 
> performance limits, I wouldn't spend a whole lot of time and effort to 
> 
> upgrade the hardware for an app that runs to completion in 60 minutes, 
> 
> versus an upgrade that allow the app to run in 40 minutes, unless that 
> 
> difference is business-relevant.
> 
> 
> 
> Now if you're considering swapping fossil-grade 15K disks for newer 10K 
> 
> disks, that could well be relevant in terns of stability and uptime.
> 
> 
> 
> > But, is there any problem with mixing 10K RPM and 15K RPM drives in a 
> 
> > shadowset?
> 
> 
> 
> You can shadow a RAM disk and a floppy disk, if you wanted to.
> 
> 
> 
> > (Except for the obvious fact that the slower disk would determine 
> 
> > system response.)
> 
> 
> 
> Not entirely true.  It'll determine the maximum write rates, certainly. 
> 
>  Reads only need to access multiple member volumes when there's an 
> 
> error.
> 
> 
> 

Actually, that faster RPM disk is only $25 which is rock bottom for new SCSI disk.  It has less capacity but more speed.  But I don't really have a business reason for faster disk except it might speed up a recovery when a system has be restarted.


> I would encourage getting yourself a formal escalation path here; 
> 
> somebody that you can discuss this stuff with.

Thanks, but we'd rather just remain sitting in this nice pot of slowing warming water.