On Fri, Sep 24, 2010 at 2:08 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Fri, 24 Sep 2010 13:43:40 -0500 > Steve French <smfrench@xxxxxxxxx> wrote: > >> It don't think it is a correctness issue - if close wants to do an >> fsync why do we have a flush routine at all? close is the only place >> flush is called. This seems very wrong to require additional >> semantics beyond Unix semantics here (and slows close performance way >> down unnecessarily). Even if we go async we would initiate i/o on >> these before we return close to the user - and we are not going to >> close the network handle of course until all network writes complete. >> >> At a minimum, we don't need to do an fsync (flush with wait) on close >> if there is more than one handle to that inode open - and should be >> able to just do flush >> > > What does this have to do with fsync? The flush operation is to flush > out data to the server prior to close. CIFS is not like a local fs or > even NFS. We have to have an open filehandle in order to write out > data. fsync is an fs file operation, handle based - so why do we need a distinct flush call if it has identical semantics? -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
