Re: cvs commit: src/tools/regression/bin/mv regress.sh

[ Available lists | Index of cvs-src | Month of Mar 2008 | Week of 18 Mar 2008 | Raw email | View thread | Wrap long lines | Reply ]
From
Diomidis Spinellis <dds@aueb.gr>
Date
18 Mar 2008 05:43:04
Subject
Re: cvs commit: src/tools/regression/bin/mv regress.sh
Message-ID
47DF5658.7060700@aueb.gr


[ Hide this part ]
Pawel Jakub Dawidek wrote:
> On Mon, Mar 17, 2008 at 05:24:00PM +0200, Diomidis Spinellis wrote:
>> Pawel Jakub Dawidek wrote:
>>> I was thinking about adding two options to cp(1) (-1 and -2) to give
>>> cp(1) a hint if the copy is done inside one disk or between separate
>>> disks. In -1 case cp(1) will read as large blocks as possible and then
>>> write them, in -2 case it will spawn two threads: one reader and one
>>> writer working in parallel. Performance improvements are very visible
>> >from what I tested.
>> Adding hints to cp(1) hinders portability. Even on the same OS, if two
>> systems have their disks differently configured, a script may end up
>> with an inappropriate hint on one of the two. Why not use fstat(2) to
>> automatically determine if the file resides on different disks, and act
>> accordingly?
>
> You can't say if this is the same disk or not. Think about more complex
> situations like partitions on RAIDs, etc.


(Or, even worse, volumes spanning multiple disks). What if cp(1) always
worked in multithread mode for large files. Is that a pessimization for
copies on the same disk? Don't disk accesses get appropriately
reordered lower down?

--
Diomidis Spinellis - http://www.spinellis.gr


Elapsed time: 0.199 seconds