On Sat, 2012-01-28 at 06:44 -0500, Jeff Layton wrote: > The SMB protocol specifies that if you don't have an oplock then writes > and reads to/from the server are not supposed to use the cache. Currently > cifs does this sort of write serially. I'd like to change it to do them > in parallel for better performance, but I'm not sure what to do in the > following situation: > > Suppose we have a wsize of 64k. An application opens a file for write > and does not get an oplock. It sends down a 192k write from userspace. > cifs breaks that up into 3 SMB_COM_WRITE_AND_X calls on the wire, > fires them off in parallel and waits for them to return. The first and > third write succeed, but the second one (the one in the middle) fails > with a hard error. > > How should we return from the write at that point? The alternatives I > see are: > > 1/ return -EIO for the whole thing, even though part of it was > successfully written? This would be the safest return. Whether it's optimal depends on how the writes are issued (and by what) and whether the error handling is sophisticated enough. > 2/ pretend only the first write succeeded, even though the part > afterward might have been corrupted? This would be what the current Linux SCSI behaviour is today (assuming the underlying storage reports it). We mark the sectors up to the failure good and then error the rest. Assuming the cifs client is sophisticated enough, it should be OK to do this, and would represent the most accurate information. > 3/ do something else? Like what? I'm assuming from the way you phrased the question the error returns in cifs aren't sophisticated enough to do one per chunk (or sector)? In linux, we could, in theory return OK for writes 1 and 3 and error write 2, but that's because we can carry one error per bio. However, we never do this because disk errors are always sequential and we'd have to have the bio boundary aligned correctly for your chunks (because a bio always completes partially beginning with good and ending with bad). James -- 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
