On 11/09/2010 02:21 PM, Jeff Layton wrote:
This does leave the page in sort of a funky state. The uptodate bit will still probably be set, but the dirty bit won't be. The page will be effectively "disconnected" from the backing store until someone writes to it. I suppose though that this is the best that can reasonably be done in this situation however...
I spent a few days looking for alternatives, and indeed I found nothing better... There are essentially two possibilities: 1) the VM can potentially be filled up with uncleanable dirty pages, or 2) pages that hit an IO error are left in a clean state, so they can be reclaimed under memory pressure Alternative 1 could cause the entire system to deadlock, while option 2 puts the onus on userland apps to rewrite the data from a failed msync/fsync. Currently the VM has behaviour #2 which is preserved with my patch. The only difference with my patch is, we won't keep returning -EIO on subsequent, error free, msync or fsync calls to files that had an IO error at some previous point in the past. -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
