db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1297) implement a derby specific "disk quota" on the data stored the database.
Date Fri, 05 May 2006 22:03:30 GMT
     [ 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

> 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:
For more information on JIRA, see:

View raw message