On Tue, Oct 29, 2013 at 01:23:19PM +0000, Myklebust, Trond wrote: > > On Oct 29, 2013, at 9:06 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > On Tue, Oct 29, 2013 at 08:50:56AM -0400, Anna Schumaker wrote: > >> On Mon 28 Oct 2013 05:40:30 PM EDT, J. Bruce Fields wrote: > >>> On Mon, Oct 28, 2013 at 10:57:25AM -0400, Anna Schumaker wrote: > >>>> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c > >>>> index 419572f..3210c6f 100644 > >>>> --- a/fs/nfsd/nfs4proc.c > >>>> +++ b/fs/nfsd/nfs4proc.c > >>>> @@ -1028,6 +1028,42 @@ nfsd4_write(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, > >>>> return status; > >>>> } > >>>> > >>>> +static __be32 > >>>> +nfsd4_write_plus_hole(struct file *file, struct nfsd4_write_plus *writeplus, > >>>> + struct net *net) > >>>> +{ > >>>> + __be32 status; > >>>> + > >>>> + status = nfsd4_vfs_fallocate(file, writeplus->wp_allocated, > >>>> + writeplus->wp_offset, writeplus->wp_length); > >>>> + if (status == nfs_ok) { > >>>> + writeplus->wp_res.wr_stid = NULL; > >>>> + writeplus->wp_res.wr_bytes_written = writeplus->wp_length; > >>>> + writeplus->wp_res.wr_stable_how = NFS_FILE_SYNC; > >>> > >>> Do we need to sync? > >> > >> I did the sync in nfsd4_vfs_fallocate (below), but I can move it if > >> that would make more sense. > > > > What I meant was--why are we doing a sync at all, instead of returning > > NFS_UNSTABLE and making the client commit? > > What if the client specifies FILE_SYNC? The spec doesn't allow the server to return UNSTABLE in that situation. Of course, sorry for being unclear. I was just wondering if there's some particular reason we're not using NFS_UNSTABLE when the client allows it. But "because it's easier" is a fine answer. We can always add that later if it turns out to be useful. --b. -- 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