Date: Thu, 13 Oct 2005 02:14:11 +0200 From: Willem Jan Withagen <wjw@withagen.nl> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-performance@FreeBSD.org, =?UTF-8?B?VHVsaW8gR3VpbWFyw6NlcyBkYSBTaWx2YQ==?= <tuliogs@pgt.mpt.gov.br> Subject: Re: dd(1) performance when copiing a disk to another Message-ID: <434DA6D3.3040309@withagen.nl> In-Reply-To: <20051004075806.F45947@delplex.bde.org> References: <20051002170446.78674.qmail@web30303.mail.mud.yahoo.com> <004701c5c77e$a8ab4310$b3db87d4@multiplay.co.uk> <434146CA.8010803@pgt.mpt.gov.br> <20051004075806.F45947@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > On Mon, 3 Oct 2005, [ISO-8859-1] Tulio Guimar�es da Silva wrote: > >> But just to clear out some questions... >> 1) Maxtor�s full specifications for Diamond Max+ 9 Series refers to >> maximum *sustained* transfer rates of 37MB/s and 67MB/s for "ID" and >> "OD", respectively (though I couldn�d find exactly what it means, I >> deduced that represents the rates for center- and border-parts of the >> disk - please correct me if I�m wrong), then your tests show you�re >> getting the best out of it ;) ; >> much slower. > > > Another interesting point is that you can often get closer to the maximum > rate than the average of the maximum and minumum rate. The outer tracks > contain more sectors (about 67/37 times as many with the above spec), so > the average rate over all sectors is larger than average of the max and > min, > significantly so since 67/37 is a fairly large fraction. Also, you can > often partition disks to put less-often accessed stuff in the slow parts. > [All GEOM alligning deleted] As it so happens, I have again some (faster) spare servers in my office. And given the NFS-tests of last year, I want to see if I could run those tests again. But before doing so I wanted to verify the extent of what Bruce suggest here above. (Which I found first in an article some time ago) I've written a small, not yet complete page, on the topic. At current it only involves writting to the disk. But it clearly visualises the effect of non-constant transferrates, which actually depends on the location of the track read from. If you want, you could see for yourself at: http://withagen.dyndns.org/FreeBSD/Performance/Raw-disk/ Suggestions etc. are welcome. --WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?434DA6D3.3040309>