db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1297) implement a derby specific "disk quota" on the data stored the database.
Date Fri, 05 May 2006 23:04:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1297?page=comments#action_12378165 ] 

Bryan Pendleton commented on DERBY-1297:

Perhaps we don't really have to be quite so accurate, but could instead implement a sort of

"approximate quota". For example, maybe it would be sufficient to compute the disk space
usage periodically, rather than keeping it constantly up to date. This means that, if we went
over the quota, we wouldn't notice until the next time that the periodic checker added up
disk space usage, but maybe that would be good enough.

For example, what if we computed the total disk space used by a segment, at each checkpoint.
We might overrun our disk quota a bit, but only until we hit the next checkpoint, at which
we'd notice that we'd hit the quota, and start failing new allocations.

This would, of course, add a bit of overhead to the checkpoint process, but only as much work
as it would take to call File.length() on each file in the segment.

Don't get too hung up on the "checkpoint" aspect of this suggestion; I'm just trying to note
we could perhaps craft an algorithm that balanced the overhead of enforcing the quota against
the accuracy of the quota, and perhaps arrive at something that is good enough for both purposes.

> 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