Messages in this thread | | | Date | Mon, 6 Sep 2004 00:02:54 -0700 | From | Andrew Morton <> | Subject | Re: Q about pagecache data never written to disk |
| |
William Lee Irwin III <wli@holomorphy.com> wrote: > > 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.
Yes, the non-void return value from set_page_dirty() is a holdover from my very early allocate-on-flush patches, wherein set_page_dirty() did indeed reserve space in the filesystem.
> 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. >
Yes. But at least _someone_ gets told that there was an ENOSPC/EIO. What are the alternatives? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |