On Wed, Jan 15, 2014 at 09:44:21AM +0000, Mel Gorman wrote: > > <SNIP> > > Hmmmm. What happens if the process crashes after pinning the dirty > > pages? How do we even know what process pinned the dirty pages so > > we can clean up after it? What happens if the same page is pinned by > > multiple processes? What happens on truncate/hole punch if the > > partial pages in the range that need to be zeroed and written are > > pinned? What happens if we do direct IO to a range with pinned, > > unflushable pages in the page cache? > > > > Proposal: A process with an open fd can hint that pages managed by this > inode will have dirty-sticky pages. Pages will be ignored by > dirty background writing unless there is an fsync call or > dirty page limits are hit. The hint is cleared when no process > has the file open. >
I'm still processing the rest of the thread and putting it into my head but it's at least clear that this proposal would only cover the case where large temporarily files are created that do not necessarily need to be persisted. They still have cases where the ordering of writes matter and the kernel cleaning pages behind their back would lead to corruption. -- Mel Gorman SUSE Labs -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
