Re: Q about pagecache data never written to disk

[William Lee Irwin III <wli@holomorphy.com>]

On Sun, Sep 05, 2004 at 09:33:44AM -0700, William Lee Irwin III wrote:
> msync(p, sz, MS_ASYNC) only does set_page_dirty() at the moment and
> returns 0 unconditionally AFAICT, so things are stuck blocking and
> waiting for disk to reap the status of the IO at all. Maybe if that
> worked the fault handling wouldn't be as important. Maybe we should be
> reaping AS_EIO and/or AS_ENOSPC in the MS_ASYNC case, or wherever it is
> we stash the fact those IO errors ever happened. I'm also not sure what
> people think would be the right way to kick off IO in the background
> there, as trying to kmalloc() a workqueue element, then doing
> schedule_work() on it has resource management issues, but forcing
> userspace to block on the IO to ensure it's been initiated at all
> defeats the point of it.

And, interestingly, the only user of the result of set_page_dirty() is
redirty_page_for_writepage(), whose results are ignored by all callers.
It appears that something is amiss here, as failed reservations aren't
reported until something attempts background writeback or IO syscalls.
That is, it would seem that checking the results of set_page_dirty(),
also called in the MS_ASYNC case, suffices, however, it does not return
useful results in most (all?) cases, and nothing now checks its result.

The calling convention looks very very odd also; filemap_fdatawait() is
the only apparent way to extract an ENOSPC result without calling the
->writepage() method directly, and this, instead of checking for things
returning -ENOSPC as one would expect, does a rather odd thing, that is
test_and_clear_bit(AS_ENOSPC, &mapping->flags), which will lose all but
one of the results whenever there are multiple concurrent callers of it
on a single inode. Worse yet, that can be legitimate, particularly when
multiple tasks concurrently msync() disjoint subsets of a file's data.


-- wli