aboutsummaryrefslogtreecommitdiffstats
path: root/fs/jbd (follow)
AgeCommit message (Collapse)AuthorFilesLines
2005-04-16[PATCH] jbd dirty buffer leak fixakpm@osdl.org1-2/+11
This fixes the lots-of-fsx-linux-instances-cause-a-slow-leak bug. It's been there since 2.6.6, caused by: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5/2.6.5-mm4/broken-out/jbd-move-locked-buffers.patch 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 list. 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 truncate-vs-commit. 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: "Stephen C. Tweedie" <sct@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds7-0/+6845
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!