Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 14 Mar 2003 14:10:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 14 Mar 2003 14:10:09 -0500 Received: from realityfailure.org ([209.150.103.212]:18948 "EHLO bushido.realityfailure.org") by vger.kernel.org with ESMTP id ; Fri, 14 Mar 2003 14:10:07 -0500 Date: Fri, 14 Mar 2003 14:20:22 -0500 (EST) From: John Jasen X-X-Sender: jjasen@bushido To: N Nair cc: linux-kernel@vger.kernel.org, Subject: Re: Posting of the Linux RAID FAQ In-Reply-To: <3E721ABB.7050401@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 960 Lines: 25 On Fri, 14 Mar 2003, N Nair wrote: > the time being? In other words can the user choose to wait and do the > resync at what he thinks is a more appropriate time - in terms of > resouce availability - ( at night, for instance ) if he is willing to > take up the risk involved ? If yes, how can the kernel raid-recovery > processes be stopped/controlled ? You have /proc/sys/dev/raid/speed_limit_max and _min, where you can specifiy upper and lower bounds for how fast the raid resyncs. I imagine you could use cron or at to whack together something to arrange higher speed resyncs during offhours. -- -- John E. Jasen (jjasen@realityfailure.org) -- User Error #2361: Please insert coffee and try again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/