Date: Fri, 2 Sep 2022 21:17:26 -0600 From: Alan Somers <asomers@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: RFC: multiple concurrent I/O ops for copy_file_range(2) Message-ID: <CAOtMX2jm7vg_38oV36UZ3LrJy-6hCF0Utk=dGCbfdsmr7sq9gQ@mail.gmail.com> In-Reply-To: <YQXPR01MB41506C61D9936C01072F6373DD7D9@YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM> References: <YQXPR01MB41506C61D9936C01072F6373DD7D9@YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 2, 2022 at 9:11 PM Rick Macklem <rmacklem@uoguelph.ca> wrote: > > Hi, > > A recent discussion involving copy_file_range(2) performance > included a suggestion that, maybe, copying of subranges > should be done concurrently. > > Although I cannot be 100% sure, I think that this would > involve using multiple kernel threads (taskqueue or similar) > to issue I/O operations on the file system(s) for blocks > (of f_iosize maybe?) concurrently, to improve performance. > > Doing this in a system call is unusual, to say the least but, then, > copy_file_range(2) is an unusual system call to begin with. > > I have not attempted to code this up as of yet. > > So, what do others think of this idea? > > rick I'm skeptical. Is the intention to speed up copying on file systems that do or don't have an efficient VOP_COPY_FILE_RANGE implementation? For those that don't, I don't see any point in trying to beat the speed of the old cp(1). Apart from the problems that we've seen around hole size, does the copy_file-range-enabled cp match the older cp's performance?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jm7vg_38oV36UZ3LrJy-6hCF0Utk=dGCbfdsmr7sq9gQ>