Battery learn-cycle = horrible write performance

[James Kunze]

I tried forcing write back with omconfig on 2950 servers where I a) had more than reasonable confidence in ups, and b) didn't care anyway because the data was replicated.  I couldn't get it to actually work.  And while delaying the learn seems to work, forcing a learn at a reasonable time does not reset the clock - in other words, the scheduled learn cycle occurs anyway.  So we have resorted to scrips that warn of impending learn cycles and delay  to quieter times.

 

From: linux-poweredge-bounces at lists.us.dell.com [mailto:linux-poweredge-bounces at lists.us.dell.com] On Behalf Of Patrick_Boyd at dell.com
Sent: Friday, July 17, 2009 7:48 AM
To: robert.vonbismarck at vtx-telecom.ch; linux-poweredge at lists.us.dell.com
Subject: RE: Battery learn-cycle = horrible write performance

 

You're probably better off delaying the battery learn till a low load time. The reason I wouldn't recommend switching it to forced write back is that the battery isn't protecting the controller cache for a sufficient period when it is in learn mode. Therefore if the server lost power you would be much more prone to data loss. This is the reason for the behavior.

 

From: linux-poweredge-bounces at lists.us.dell.com [mailto:linux-poweredge-bounces at lists.us.dell.com] On Behalf Of Robert von Bismarck
Sent: Friday, July 17, 2009 8:35 AM
To: linux-poweredge-Lists
Subject: Battery learn-cycle = horrible write performance

 

Hi guys,

 

We have a PE1950III with a PERC6 and two 15k 74Gb disks in RAID 1. This server runs a telephony app that is pretty verbose and hits the disk pretty hard (5Mb/s sustained). During the battery learn-cycle the performance drops, and the load on the server goes through the roof, until the controller is satisfied that the battery is ok. In the logs we see that the controller sets the cache to write-through for this operation. This is a pretty sensible thing to do, but it usually happens late at night, and our duty tech gets woken up because it triggers our monitoring system.

 

Going through the OMSA documentation, we found that we could set the cache to "Force Write-Back" with omconfig 

 

omconfig storage vdisk action=changepolicy writepolicy=fwb controller=0 vdisk=0 (untested command)

 

Would enabling this over an extended period be bad, or would it be better to enable it before the learn-cycle and disable it right after it's done ?

 

 

Thanks for any hints,

 

Robert von Bismarck
Senior Systems Engineer

 


VTX SERVICES SA
Une société du groupe VTX Telecom
================================================================
Tél : 021 721 11 11 - Mobile : 079 541 37 28 - VoIP VTX 062 503 79 05
Av. de Lavaux 101 - 1009 Pully
http://www.vtx.ch <blocked::http://www.vtx.ch/>  - robert.von bismarck at vtx-telecom.ch <blocked::mailto:bismarck at vtx-telecom.ch> 
----------------------------------------------------------------
VTX, votre partenaire telecom proche de vous !
================================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20090717/f095ddef/attachment.htm