db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5738) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE only returns to the OS pages in the last extent
Date Tue, 16 Apr 2013 16:55:16 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-5738:

    Component/s: Store
> SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE only returns to the OS pages in the last extent
> ---------------------------------------------------------------------------------------
>                 Key: DERBY-5738
>                 URL: https://issues.apache.org/jira/browse/DERBY-5738
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,,,,,,,
>            Reporter: Mike Matrigali
> It looks like inplace compress only gives back space to the OS from the empty pages in
the last extent of the file.  If the defrag and purge phases are
> run they can reclaim internal space in the form of free pages to be used for future inserts,
but free pages before last extent are not returned to 
> OS.   
> Only current workaround is to use SYSCS_UTIL.SYSCS_COMPRESS_TABLE instead.
> In filecontainer.java!compressContainer there is a comment with steps to be performed,
but no code exists for step 5 and 6:
>       This is outline of the algorithm used in compressing the container.
>       Until a non free page is found loop, in each loop return to the OS
>          all space at the end of the container occupied by free pages, including
>          the allocation page itself if all of it's pages are free.
>       1) Find last 2 allocation pages in container (last if there is only one).
>       2) invalidate the allocation information cached by the container.
>          Without the cache no page can be gotten from the container.  Pages
>          already in the page cache are not affected.  Thus by latching the
>          allocPage and invalidating the allocation cache, this NTT blocks out
>          all page gets from this container until it commits.
>       3) the allocPage determines which pages can be released to the OS,
>          mark that in its data structure (the alloc extent).  Mark the
>          contiguous block of nallocated/free pages at the end of the file
>          as unallocated.  This change is associated with the NTT.
>       4) The NTT calls the OS to deallocate the space from the file.  Note
>          that the system can handle being booted and asked to get an allocated
>          page which is past end of file, it just extends the file automatically.
>       5) If freeing all space on the alloc page, and there is more than one
>          alloc page, then free the alloc page - this requires an update to the
>          previous alloc page which the loop has kept latched also.
>       6) if the last alloc page was deleted, restart loop at #1

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message