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] [Commented] (DERBY-5738) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE only returns to the OS pages in the last extent
Date Wed, 02 May 2012 23:13:47 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267000#comment-13267000
] 

Mike Matrigali commented on DERBY-5738:
---------------------------------------

implementing the restart loop should be easy.

implementing deallocating the last alloc page may be hard.  The code does return that it emptied
all the pages, so
that part is easy to know that you should do it.  I don't know if proper log records exist
to safely do the remove of
the last alloc page, such that redo and undo works properly.  may need a new operation.
                
> 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
>    Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1,
10.8.2.2
>            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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message