<div>Well just generally I was thinking about a block design, spending some money for extra 1) cooling, 2) shielding, and 3) power, for overlapping sections of the cluster, and see if the incidence rate of failures correlates with anything. You can imagine stacking your nodes in a (3-dimensional) cube; the top X percent get extra shielding, the front X get cooling, and the right X get power. If X is 50% you are spending alot of time and money on the experiment but would get a statistically meaningful result (which might be no correlation at all) in a few weeks; if X is tiny you would have to wait long enough for a random failure to occur in the uprgraded volumes, so you'd invest less but have a longer wait. If this is has been an issue for a long time and the expected working lifetime of the cluster is long into the future, it could be worth doing something like this for X fairly small. A side-benefit would be data for a broader cost-benefit analysis of plausible upgrades, if you can measure other performance characteristics besides the failures.

</div>

<div>Peter<br><br> </div>

<div><span class="gmail_quote">On 5/23/07, <b class="gmail_sendername">Mark Hahn</b> <<a href="mailto:hahn@mcmaster.ca">hahn@mcmaster.ca</a>> wrote:</span>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> I still don't know whether this is a problem of the linux kernel sata driver,<br>> a hardware problem, a flaw of the disk firmware or something else. I'm

the logs show that a command times out, and defies recovery.  I don't think your chipset is the most common - is the SATA controller integrated, or something like a Promise chip? do you have any guess about whether your disks are getting enough power?

it seems to be a fairly common occurrance for people to report this kind of "stops working" bug to the list (<a href="mailto:linux-ide@vger.kernel.org">linux-ide@vger.kernel.org</a>), only later to discover that the problem was a marginal power supply.

<br><br>> looking for a possibilty to track down the problem without substantially<br>> interfering with the jobs on the cluster.<br><br>the sata developers hang out on linux-ide, and seem very responsive.<br>quite a lot of work has been done on exception handling, but as always,

<br>it's the most common controllers which are best tested/supported.<br><br>> I tried several linux kernel versions (eg. <a href="http://2.6.18.1">2.6.18.1</a>, currently: <a href="http://2.6.20.3">2.6.20.3</a><br>

> from <a href="http://kernel.org">kernel.org</a>) which seems to make no difference.<br><br>well, by kernel standards, <a href="http://2.6.20.3">2.6.20.3</a> is fairly old; there have certainly been<br>plenty of SATA updates this year.

<br><br>> I also tried to reduce SATA bandwidth down to 150MB/s with a jumper at<br>> the disk. This does not help either.<br><br>it wouldn't, unless you had a noise problem with the cable.<br><br>> NCQ is disabled:

<br>> # cat  /sys/block/sda/device/queue_depth<br>> 1<br><br>such features wouldn't cause the fairly low-level hang in your logs -<br>to me it looks like power, given that it appears to affect even the phy-level

disk interface.  it wouldn't hurt to see what smart says about it (health, metrics and even a self-test.)  you might also try stressing the disk with IO to see whether you can repeatably trigger the problem.

<br><br>regards, mark hahn.<br>_______________________________________________<br>Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a><br>To change your subscription (digest mode or unsubscribe) visit 

<a href="http://www.beowulf.org/mailman/listinfo/beowulf">http://www.beowulf.org/mailman/listinfo/beowulf</a><br></blockquote></div><br>