On Fri, Apr 14, 2017 at 05:22:13PM -0400, Olga Kornievskaia wrote: > On Fri, Apr 14, 2017 at 4:09 PM, Mora, Jorge <Jorge.Mora@xxxxxxxxxx> wrote: > > On 4/13/17, 11:45 AM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > >> Are you timing just the copy_file_range() call, or do you include a > >> following sync? > > > > I am timing right before calling copy_file_range() up to doing an fsync() and close() of the destination file. > > For the traditional copy is the same, I am timing right before the first read on the source file up to the > > fsync() and close() of the destination file. > > Why should do we need a sync after copy_file_range(). kernel > copy_file_range() will send the commits for any unstable copies it > received. Why does it do that? As far as I can tell it's not required by documentation for copy_file_range() or COPY. COPY has a write verifier and a stable_how argument in the reply. Skipping the commits would allow better performance in case a copy requires multiple COPY calls. But, in any case, if copy_file_range() already committed then it probably doesn't make a significant difference to the timing whether you include a following sync and/or close. --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
