On Sat, 11 Dec 2010 22:47:42 +0300 Pavel Shilovsky <[email protected]> wrote:
> 2010/12/7 Jeff Layton <[email protected]>: > > Hmmm...that looks a little ugly. There is no batching here, so if the > > application sends you an array of very small iovecs, then that becomes > > a set of very small reads on the wire. I don't think that's what you > > want. > > Jeff, I investigated this a little and found out a problem with > mandatory byte-range locks: > > For example, the first user locks file from 11 to 12, the second user > specifies two buffers with 10 and 20 lengths and wants to fill them > with readv call. In your case we merge these buffers into one request, > sends it and got error. As the result we don't have any data returned > from the server. So the second user thinks that the file is locked on > both regions (from 0 to 10 and from 10 to 30) but it is not true! > Almost the same things we can see in write case. So, what's why I > think we shouldn't do it in strict cache case. > > Thoughts? > I think that the number of buffers to be filled shouldn't affect the behavior of the client on the wire. If someone happens to trip over a BRL here, then tough luck for them. The multiple buffer case is really no different than the case of a single buffer, other than the fact that you're stuffing the result into multiple buffers rather than a single one. We're certainly under no obligation to partially satisfy a read or write in such a case. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
