If you look closely, I essentially got rid of all write canceling. It's
basically never the right thing to do. It's still done if
- the server tells us that the file has radically changed from under us
(ie catastrophic failure, like the file suddenly having turned into a
directory etc: this should _never_ happen with a proper NFS server, as
we should really have gotten a "Stale file handle" error instead)
- there's code to do it for nfs_delete_inode(), but that function should
never be called with pending writes any more, so that code could just
be deleted.
> - Shouldn't a cancellation also invalidate the page if it was marked
> PG_uptodate?
If it were to happen (see above) it already should. When we cancel the
request, the request will finish incomplete, and the nfs_wback_result()
function should clear the uptodate flag.
> - Another (minor) point is whether nfs_cancel_dirty should really be
> cancelling unfreed write requests that are marked as
> NFS_WRITE_COMPLETE?
Again, it shouldn't really be an issue, but basically it shouldn't matter
anyway.
> - If you run 'setattr' on a file in order to truncate it, there is no
> synchronization to ensure that async writes which would be cancelled
> are committed before the call to setattr.
Good point. Feel free to send me patches, hint, hint.
> - If you read a page and the call to nfs_wb_page fails, the PG_locked bit
> is never cleared, and many processes end up hanging on wait_on_page.
> (Please note my first patch to cure this contained a bug in that it didn't
> free the page in the case of a successful synchronous read).
Good spotting, I'll fix this.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/