Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C665D909B for ; Mon, 12 Mar 2012 01:51:52 +0000 (UTC) Received: (qmail 30046 invoked by uid 500); 12 Mar 2012 01:45:11 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 29966 invoked by uid 500); 12 Mar 2012 01:45:11 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 29953 invoked by uid 99); 12 Mar 2012 01:45:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Mar 2012 01:45:10 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com designates 209.85.210.52 as permitted sender) Received: from [209.85.210.52] (HELO mail-pz0-f52.google.com) (209.85.210.52) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Mar 2012 01:45:03 +0000 Received: by dadp12 with SMTP id p12so5542601dad.11 for ; Sun, 11 Mar 2012 18:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=RTkZ9wCx/ANDjvs/4n3DWrq1EtfCQ2RmoOaxMKrUJe0=; b=E4zVyMW1QkCah0R9Qoqj0TGFITlouqD3TzkNs6Dm0qnUga94n1wyH7sfuVal+3+EGQ LCXIbRnmLOSk3KOgbLeYetkQKvxNa4CxxFgn7wpg51k6NNnFyl5WOgYCx8klJ80ZF1UI 8pyez631QzgW/jjC4UhHYa3czEZpEd9Y3pDJA0LiXVf0cHYb8r3zGJfuPaLe5CcDs46I DALr1hFK75WLmwWxSeNc83bnk58TEJFApT3KYodArAgoujk36nHxb5CpvneEkEP/qvMG gwFcEcEi9x0c4myo2Yb4Wh+Buw8Hoz80bgxyKAiKVvzzuSfas4bLDsKRPScJJZ5cVSK6 L0+g== MIME-Version: 1.0 Received: by 10.68.220.10 with SMTP id ps10mr4776146pbc.94.1331516681876; Sun, 11 Mar 2012 18:44:41 -0700 (PDT) Received: by 10.68.216.67 with HTTP; Sun, 11 Mar 2012 18:44:41 -0700 (PDT) In-Reply-To: <4F5CBD3A.3050001@gmail.com> References: <5D5AF65F-88FE-4A19-8D92-800E956235B6@apache.org> <26E0BD0D-0047-44B1-925C-BBA68A3448A3@apache.org> <4F4FC68D.7080206@gmail.com> <697FCEB2-0071-4F08-A463-A073DBA0B315@apache.org> <4F5C9FAD.2040300@gmail.com> <4F5CBD3A.3050001@gmail.com> Date: Sun, 11 Mar 2012 18:44:41 -0700 Message-ID: Subject: Re: Crash of CouchDB 1.2.x From: Randall Leeds To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Sun, Mar 11, 2012 at 07:56, Stefan K=C3=B6gl wro= te: > On 03/11/2012 02:32 PM, Jason Smith wrote: >> >> Longshot, but is it possible that couch had a file handle to an >> unlinked file, so once the (OS) process crashed, the space was >> freed? > > > Hmm.. that might be possible. I ran a database compaction before that. Wh= en > I noticed the crash I saw that the db compaction finished, but it might b= e > possible that it still had a handle to the old db file. {badmatch,{error,enospc}} is exactly the out of space error coming straight up out of the kernel. > > How should we proceed from here? Is it possible for me to provide further > information about that in retrospect? I'm not sure what else you could provide after the fact. If your couch came back online automatically, and did so quickly, I would expect to see very long response times while the disk was busy freeing the old, un-compacted file. We have had some fixes in the last couple releases to address similar issues, but maybe there's something lurking still. I've got no other ideas/leads at this time. > > > -- Stefan