On Wed, Mar 21, 2012 at 4:47 PM, Myklebust, Trond <Trond.Myklebust@xxxxxxxxxx> wrote: > On Wed, 2012-03-21 at 15:46 -0400, andros@xxxxxxxxxx wrote: >> From: Andy Adamson <andros@xxxxxxxxxx> >> >> The return is ignored. > > Yes, but should it be? See the discussion between Fred and myself on the > list yesterday. I still don't see why we should report some errors and > ignore others... > > I'll come back to this in a day or two, but let me note the following problem with nfs_commit_inode, pnfs, and error reporting. Consider nfs_wb_page, which causes a FLUSH_SYNC nfs_commit_inode. Pre-pnfs, nfs_commit_inode either returned an error, or sent the COMMIT. Even if the page didn't make it into the "to be cleaned" list due to the INT_MAX restriction, the COMMIT was sent and on non-eror return it was safe to assume that the page data was on disk. But with pnfs (and commit to DS), lets say that the writes are distributed between 2 data servers. On a non-error return from nfs_commit_inode there is now no guarantee that a COMMIT will go to the DS hosting the page. That is solely due to the INT_MAX restriction. It of course gets even worse with the current filelayout_commit_pagelist if an alloc fails. Fred -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html