Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7C19B9842 for ; Tue, 10 Apr 2012 16:45:49 +0000 (UTC) Received: (qmail 53169 invoked by uid 500); 10 Apr 2012 16:45:47 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 53142 invoked by uid 500); 10 Apr 2012 16:45:47 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 53134 invoked by uid 99); 10 Apr 2012 16:45:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Apr 2012 16:45:47 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [92.60.177.132] (HELO web1.alefhost.od.ua) (92.60.177.132) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Apr 2012 16:45:39 +0000 Received: from [10.0.2.15] (unknown [78.26.128.183]) by web1.alefhost.od.ua (Postfix) with ESMTPSA id D90C9249DB for ; Tue, 10 Apr 2012 19:45:40 +0300 (EEST) Message-ID: <4F84639D.7050304@4friends.od.ua> Date: Tue, 10 Apr 2012 19:45:17 +0300 From: Igor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: user@cassandra.apache.org Subject: Re: Repair Process Taking too long References: <4F8446F0.7070906@4friends.od.ua> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050204020908000901000302" This is a multi-part message in MIME format. --------------050204020908000901000302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/10/2012 07:16 PM, Frank Ng wrote: Short answer - yes. But you are asking wrong question. > I think both processes are taking a while. When it starts up, > netstats and compactionstats show nothing. Anyone out there > successfully using ext3 and their repair processes are faster than this? > > On Tue, Apr 10, 2012 at 10:42 AM, Igor > wrote: > > Hi > > You can check with nodetool which part of repair process is slow > - network streams or verify compactions. use nodetool netstats or > compactionstats. > > > On 04/10/2012 05:16 PM, Frank Ng wrote: > > Hello, > > I am on Cassandra 1.0.7. My repair processes are taking over > 30 hours to complete. Is it normal for the repair process to > take this long? I wonder if it's because I am using the ext3 > file system. > > thanks > > > --------------050204020908000901000302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/10/2012 07:16 PM, Frank Ng wrote:

Short answer - yes.
But you are asking wrong question.

I think both processes are taking a while. When it starts up, netstats and compactionstats show nothing. Anyone out there successfully using ext3 and their repair processes are faster than this?

On Tue, Apr 10, 2012 at 10:42 AM, Igor <igor@4friends.od.ua> wrote:

Hi

You can check with nodetool which part of repair process is slow - network streams or verify compactions. use nodetool netstats or compactionstats.

On 04/10/2012 05:16 PM, Frank Ng wrote:

Hello,

I am on Cassandra 1.0.7. My repair processes are taking over 30 hours to complete. Is it normal for the repair process to take this long? I wonder if it's because I am using the ext3 file system.

thanks

--------------050204020908000901000302--