Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 24672 invoked from network); 24 Dec 2010 10:46:57 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 24 Dec 2010 10:46:57 -0000 Received: (qmail 47341 invoked by uid 500); 24 Dec 2010 10:46:55 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 47322 invoked by uid 500); 24 Dec 2010 10:46:55 -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 47314 invoked by uid 99); 24 Dec 2010 10:46:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Dec 2010 10:46:55 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.160.172] (HELO mail-gy0-f172.google.com) (209.85.160.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Dec 2010 10:46:46 +0000 Received: by gyd12 with SMTP id 12so3151637gyd.31 for ; Fri, 24 Dec 2010 02:46:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.138.2 with SMTP id l2mr13720633ybd.261.1293187583882; Fri, 24 Dec 2010 02:46:23 -0800 (PST) Sender: scode@scode.org Received: by 10.150.220.9 with HTTP; Fri, 24 Dec 2010 02:46:23 -0800 (PST) X-Originating-IP: [213.114.156.79] In-Reply-To: <5707DE2F-542A-4C9C-8780-C68D51A6B55B@toptarif.de> References: <072D2793-F328-441C-8A24-1353B78B18A1@toptarif.de> <5707DE2F-542A-4C9C-8780-C68D51A6B55B@toptarif.de> Date: Fri, 24 Dec 2010 11:46:23 +0100 X-Google-Sender-Auth: oqshvwJKiUJjVflHgxlOBbeGj5U Message-ID: Subject: Re: java.io.IOException: No space left on device From: Peter Schuller To: user@cassandra.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org >> In any case: Monitoring disk-space is very very important. > > So, why doesn't cassandra monitor it itself and stop accepting writes if it runs out of space? For one thing, it's non-trivial to do accurately because disk space usage varies over time due to background compaction and/or anti-compaction. Compaction will require different amount of diskspaces depending on the nature of writes (e.g., if all writes are removals compaction takes much less space than if all writes are non-overwriting inserts). Maybe the maximum possible disk space use can be kept track of in a conservative fashion (assuming all writes are non-overwriting inserts, assuming a maximally disk-space intensive repair will be run, etc) and then behave appropriately based on that. If someone has a use case where the cluster is sufficiently close to running out of disk space (but it works for the particular use-case), such a feature could be turned off. But it would make it less easy to accidentally write yourself into a corner. -- / Peter Schuller