Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 4050 invoked from network); 5 May 2006 22:04:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 May 2006 22:04:17 -0000 Received: (qmail 55835 invoked by uid 500); 5 May 2006 22:04:09 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 55602 invoked by uid 500); 5 May 2006 22:04:08 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 55519 invoked by uid 99); 5 May 2006 22:04:08 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 May 2006 15:04:07 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 May 2006 15:04:06 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 8AAD67142C1 for ; Fri, 5 May 2006 22:03:30 +0000 (GMT) Message-ID: <19581156.1146866610556.JavaMail.jira@brutus> Date: Fri, 5 May 2006 22:03:30 +0000 (GMT+00:00) From: "Mike Matrigali (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-1297) implement a derby specific "disk quota" on the data stored the database. In-Reply-To: <6242134.1146865527602.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1297?page=all ] Mike Matrigali updated DERBY-1297: ---------------------------------- The following comments assume the current file per index/table allocation implementation. An alternate implmentation which used a 1 file with multiple table/indexes model would present different challenges. I don't believe java gives a good way to track space used in the filesystem by directory, so I think the only option here is for the storage engine to maintain the data itself. This would mean some new, on disk, logged data structure --- with information about all the allocation maps in the system. No obvious place jumps to mind, seems like a new store specific system catalog would be necessary. This is not that hard, just different from the current implementation where all the store specific metadata is associated with the tables themselves, either in the container header or in special control rows in the page 1 of the file. One downside of this feature is that it will introduce another point of contention that could possible reduce throughput in a multi-user system. Currently allocation to 2 different files requires no coordination between threads, this feature would require some sort of coordination for every allocate, file creation, file drop, and compress table operation. > implement a derby specific "disk quota" on the data stored the database. > ------------------------------------------------------------------------- > > Key: DERBY-1297 > URL: http://issues.apache.org/jira/browse/DERBY-1297 > Project: Derby > Type: New Feature > Reporter: Mike Matrigali > Priority: Minor > > Implement some way for users to indicate the amount of disk space in a specific segment of the database. Current derby data files in one database can only reside in a single segment, but it would be good to consider implementation of the storage module which could allow data across multiple segments. In the current implementation Derby just uses the space available in the current seg0 directory until an allocation fails, subsquent attempts to grow the database result in errors for the associate insert or update statement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira