Computing desk
< October 2	<< Sep \| October \| Nov >>	October 4 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

October 3

Hard disk orientation to maximize device lifetime

I have heard four conflicting claims regarding the effect of horizontal/vertical orientation on how long external hard disk drives last (that is, the device lifetime):

External hard disk drives last longest if placed in a horizontal orientation because the platter then spins evenly underneath the head under the influence of gravity (that is, force exerted by gravity is always the same at every point in each spin cycle).
External hard disk drives last longest if placed in a vertical orientation because the platter then spins with least friction/resistance, since gravity is not pushing the head against the platter, nor the platter against any surface below it.
External hard disk drives last longest if placed in the orientation, whether horizontal or vertical, indicated by the manufacturer's logo/label or the physical stand, since the manufacturer would have designed the hard drive to be placed in the orientation implied by that logo/label or stand.
Hard disk drives do not last any longer or shorter based on whether they are placed in a horizontal or vertical orientation.

Which of these four claims is true? How should I orient my external hard drives to maximize their lifetimes? —SeekingAnswers (reply) 07:06, 3 October 2012 (UTC)[reply]

Google's servers use horizontally orientated drives. I think that Google would have thought about this, as they go through many, many drives. — Preceding unsigned comment added by 217.158.236.14 (talk) 11:19, 3 October 2012 (UTC)[reply]

Also there is no friction or noticeable gravitational push pressing the heads onto the platters. They "fly" on the air drawn around by the platter which they are accessing.--Phil Holmes (talk) 11:26, 3 October 2012 (UTC)[reply]

Every modern hard drive technical spec I've ever looked at says that they can be mounted at any angle, and recommend not moving them around once they are running. That implies that if there is a slight advantadge to a particular orientation then it isn't something the manufacturer considers noteworthy. You could always look up the spec for your particular drive to be sure. It sounds like you're using an external drive, so the only thing I would worry about is making sure that any ventilation holes are unobstructed. 209.131.76.183 (talk) 11:50, 3 October 2012 (UTC)[reply]

I can attest to the not moving them around when connected. Mine still works perfectly fine, but I've pulled it around so much that it will often disconnect and reconnect to the computer if it even moves around a little now. - Purplewowies (talk) 13:02, 3 October 2012 (UTC)[reply]

Various storage arrays from Oracle, IBM, Netapp, HDS, HP, and Dell use drives in flat (label side up) and on edge (label side left or right) configuration. Oracle's Thumper and Thor arrays, which have pull-out trays, have the drives in connector-down orientation. Dell's Precision desktop machines have the drives in a connector-up orientation. So they're all orienting the disks in a way that suits their chassis, cable routing, and cooling strategy. There's no consensus orientation, because there's no advice from any HDD maker that orientation matters. -- Finlay McWalterჷTalk 14:15, 3 October 2012 (UTC)[reply]

DB2 optimization

Can't seem to find the details regarding this particular db2 sql query optimization; i got told, so long ago, that the query optimizer was smart enough not to deal with unneeded columns; i.e., if i wrote

select a.foo, b.foo2 
from a left join 
(select * from b 
where foo2 > 0)
on a.foo = b.foo

it would be smart enough to just handle columns foo and foo2 from table b. Anyway, we got upgraded to version 10, and this doesn't seem to be the case; I need to specify

...
(select foo, foo2 from b 
where foo2 > 0)
...

instead to get it to run. Was it the case that this was an optimization? Is it no longer the case? Thanks. Gzuckier (talk) 07:46, 3 October 2012 (UTC)[reply]

Not sure, but you are explicitly asking it to return all columns from b, so I can see why they might not want to override that. It would be different if you wrote:

SELECT a.foo, b.foo2
  FROM akbar a,
       berny b
 WHERE a.foo = b.foo
   AND b.foo2 > 0;

In this case you don't explicitly specify to retrieve all columns from b, so it's reasonable to expect it to only fetch the ones it needs. StuRat (talk) 08:18, 3 October 2012 (UTC)[reply]

yeah, you'd think it would be easy enough to write db2 optimizer code which could see which columns are used in the query and use that instead of the *..... oh well. Gzuckier (talk) 16:43, 3 October 2012 (UTC)[reply]

It is, but it's one thing when you say "retrieve whatever you need to" and quite another when you say "retrieve all this stuff you don't need". In the one case optimization is doing what you asked, while, in the other, it's going counter to what you asked. Since there might be some reason why the user prefers the non-optimized version, overriding what they asked for is a questionable practice. Think of it like an auto-correct spellchecker in a word processor. Sure, most of the time it may make good corrections, but, on occasion, it will make a "correction" you don't want (let's say you are writing dialog and are trying to show a dialect by including words like "aint").

A possible improvement they could make in the DB2 case is to have a setting which controls whether it optimizes queries where you've intentionally asked for it to do things in an inefficient manner. Perhaps a future DB2 version could also offer an alternative to "*", meaning "all". How about "?", meaning "just what is needed" ? StuRat (talk) 18:35, 3 October 2012 (UTC)[reply]

Would DB2 really find itself to be forced to execute the obviously inefficient query, given that there's no way a user could tell the difference by the end result (the final selected columns are the same...) - either DB2 would truly suck, or there is something much more subtle going on. Unilynx (talk) 21:01, 3 October 2012 (UTC)[reply]

No, that does make sense; there is nothing more infuriating than something that won't let you overrule the defaults, optimizations, etc. because the designer didn't see any reason why you would ever want to. Gzuckier (talk) 06:17, 4 October 2012 (UTC)[reply]

I can't see why you would ever want to. Can you give an example? -- BenRG (talk) 04:04, 5 October 2012 (UTC)[reply]

Well, say you want your own code to be optimized, so that, if you transfer it to a different platform which does the optimization differently, you don't have to worry about it slowing down. In this case, you wouldn't want it optimizing it for you, as this would obscure the optimization level of your own code. Another (admittedly poor) practice might be to make it intentionally inefficient so that the data scrolls by at a slower pace which you can read. StuRat (talk) 16:54, 6 October 2012 (UTC)[reply]