Messages in this thread | | | Date | Thu, 17 Dec 1998 08:54:04 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: NFS client write out corrupted file? |
| |
On 17 Dec 1998, Trond Myklebust wrote: > > There are still a few issues remaining in pre-patch-2.1.132-1 though. > > - There remains an ambiguity concerning the status of cancelled writes: > if they were already in progress, they may still be committed to the > server's storage, but this will not be registered by the inode > attribute cache.
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/
| |