• akpm@osdl.org's avatar
    [PATCH] jbd dirty buffer leak fix · d13df84f
    akpm@osdl.org authored
    This fixes the lots-of-fsx-linux-instances-cause-a-slow-leak bug.
    It's been there since 2.6.6, caused by:
    That patch moves under-writeout ordered-data buffers onto a separate journal
    list during commit.  It took out the old code which was based on a single
    The old code (necessarily) had logic which would restart I/O against buffers
    which had been redirtied while they were on the committing transaction's
    t_sync_datalist list.  The new code only writes buffers once, ignoring
    redirtyings by a later transaction, which is good.
    But over on the truncate side of things, in journal_unmap_buffer(), we're
    treating buffers on the t_locked_list as inviolable things which belong to the
    committing transaction, and we just leave them alone during concurrent
    The net effect is that when truncate tries to invalidate a page whose buffers
    are on t_locked_list and have been redirtied, journal_unmap_buffer() just
    leaves those buffers alone.  truncate will remove the page from its mapping
    and we end up with an anonymous clean page with dirty buffers, which is an
    illegal state for a page.  The JBD commit will not clean those buffers as they
    are removed from t_locked_list.  The VM (try_to_free_buffers) cannot reclaim
    these pages.
    The patch teaches journal_unmap_buffer() about buffers which are on the
    committing transaction's t_locked_list.  These buffers have been written and
    I/O has completed.  We can take them off the transaction and undirty them
    within the context of journal_invalidatepage()->journal_unmap_buffer().
    Acked-by: default avatar"Stephen C. Tweedie" <sct@redhat.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>