Date: Tue, 7 Apr 1998 15:19:29 -0700 (PDT) From: Tom <tom@sdf.com> To: Kyle McPeek <kyle@stdio.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: CAM Performance... Message-ID: <Pine.BSF.3.95q.980407151409.1914A-100000@misery.sdf.com> In-Reply-To: <Pine.SUN.3.91.980407152121.26432B-100000@heathers2.stdio.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Apr 1998, Kyle McPeek wrote: > Hi All, > > For a project at work I need to be able to write 400MB sequentially to an > Ultra-Wide harddisk (Seagate ST32171W 2GB) from an nfs mounted drive as > fast a possible. right now we have it down to around 3:45 seconds using > the old scsi code. > > I am using dd with bs=27163 (Approximately = data on one track) to write > to /dev/rsd0s2c. Why that block size? I think you will be much better with 64k blocks. How a particular drive organizes data to tracks is almost impossible to tell. Using a block size which is not a multiple of 512 almost certainly slows things down. Since you going for NFS to disk, is the bottleneck the disk or the network? If it is the disk, use two stripped drives for better performance. > Would the cam code improve sequential scsi writes? Also, what sort of > general speed improvements has everyone seen using the cam code? Probably not. CAMs main benefits are better error recovery, and better handling of lots of simultaneous i/o. Softupdates would improve things a lot for this application (esp if you have lots of RAM), but they don't work yet > I do still plan to test the cam code myself, but I would like to know > what other people have experienced. > > Kyle McPeek > TEKsystems Consultant at > Lexmark International. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.980407151409.1914A-100000>