You are right, network bandwidth is not the issue - but we can get info on the underlying filesystem, and perhaps use the FS info (on sector size etc.) that David noted to control the size we request - and the number of credits and variations in response time as hints to control how many copychunk requests we send at one time. On Tue, Oct 1, 2013 at 4:05 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Thu, Sep 26, 2013 at 12:22:49PM -0500, Steve French wrote: >> >>> I suppose, but can't the app achieve a nice middle ground by copying the >> >>> file in smaller syscalls? Avoid bulk data motion back to the client, >> >>> but still get notification every, I dunno, few hundred meg? >> >> Yes. And if "cp" could just be switched from a read+write syscall >> >> pair to a single splice syscall using the same buffer size. >> > Will the various magic fs-specific copy operations become inefficient >> > when the range copied is too small? >> >> Yes - it is much less efficient for the network file system cases when >> copy size is small. Reasonable minimum is probably at least 1MB. >> Windows will use up to 16MB, but a saner approach to this would base >> the copy chunk size on either response time or on network bandwidth >> for the connection. >> >> Copy offload has been done for a long time with CIFS/SMB2/SMB3 >> protocol (and obviously helps a lot more over the network for file >> copies than locally), but only recently have we added support for this >> in Samba through David Disseldorp's work. i have kernel patches >> almost ready to post for cifs.ko for the client side to do copy >> offload (cp --reflink) via CopyChunk fsctl over SMB3 which is >> supported by most all servers now. >> >> Windows clients seem to max out at 16MB chunk size when doing copy >> offload. I would like to increase chunk size larger than that if >> network bandwidth (returned at mount time in SMB3 on the query network >> interfaces FSCTL) is large enough, and response time is not more than >> 100 (?) milliseconds. > > I'm confused--copy offload means no data's going over the network, so > why would network bandwidth be a factor at all? > > (Or are you talking about some kind of server-to-server bandwidth?) > > --b. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
