Date: Tue, 18 Mar 2008 07:42:48 +0200 From: Diomidis Spinellis <dds@aueb.gr> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, Alfred Perlstein <alfred@FreeBSD.org>, Diomidis Spinellis <dds@FreeBSD.org>, src-committers@FreeBSD.org Subject: Re: cvs commit: src/tools/regression/bin/mv regress.sh Message-ID: <47DF5658.7060700@aueb.gr> In-Reply-To: <20080317235900.GA25950@garage.freebsd.pl> References: <200712180849.lBI8nmEi088947@repoman.freebsd.org> <20071218100355.GR16982@elvis.mu.org> <20080314223652.GA20470@garage.freebsd.pl> <47DE8D10.9090201@aueb.gr> <20080317235900.GA25950@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47DF5658.7060700>