[ 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
