[jira] [Updated] (DERBY-5738) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE only returns to the OS pages in the last extent

["Mike Matrigali (JIRA)" <ji...@apache.org>]

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

Mike Matrigali updated DERBY-5738:
----------------------------------
      Issue & fix info: High Value Fix
    Bug behavior facts: Seen in production
                Labels: derby_triage10_12  (was: )

10.12 triage effort.  This would be a very useful fix/improvement.  At this point I only recommend users use off line compress to be safe.

> 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: 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
>              Labels: derby_triage10_12
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)