Date: Sun, 15 Nov 1998 11:41:23 -0800 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au (Mike Smith), peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone Message-ID: <199811151941.LAA13761@dingo.cdrom.com> In-Reply-To: Your message of "Sun, 15 Nov 1998 19:13:37 GMT." <199811151913.MAA27668@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Actually, I could see it being *very* useful for copying data between > > > plexes on different volumes for the purpose of replication. > > > > How? Please note the quantum effects I've mentioned previously, and > > note that the only useful way to overcome them is to enable buffering > > at both ends of the queue. Please also study the internal architecture > > of most SCSI disks and note the almost total decoupling between the > > head/spindle location and the availability of a request for > > presentation to the bus. > > > > Spindle sync was useful back when data off the drive was basically the > > output of the head preamp or the data separator. It's not noticeably > > useful as soon as you allow the drive to do things for it's own reasons. > > It's not clear to me that spindle sync, with various drive > performance features enabled, actually refers to anything more > than cylinder selection; i.e., that you couldn't argue that > drive-level optimizations, e.g., write caching, are lower level > than spindle sync. In other words, at what level do you actually > engage in synchronization? Good question. Unless it's enforced as a two-way protocol-level heartbeat (it's not on any drive I'm aware of - they all output a square wave from the master and expect one on the slave), it can only be used as a master reference for the spindle index PLL, which takes us back to my original arguments. > > > Bringing a new disk online in a RAID 5 array could also use this > > > to advantage. > > > > What you want is the SCSI COPY command. > > Yes. And if the second drive never had to seek except when the > first was also seeking, and seeking took the same time because > the rotation rates were the same and the seek was between the > same cylinder... Then the first time the second disk had to seek unexpectedly because of a forwarded sector, or the first time that someone else wanted to use the SCSI bus, everything would come unstuck. Even then, you don't want them in sync, you want the second drive lagging the first by something slightly more than the total latency from the first drive's head to the second drive's head, eg. head preamp, data separator, sector deformatter, ECC, sector buffering, transfer construction, cache overhead, SCSI command and data overhead, command deconstruction, sector ECC construction, sector servo request, and all the other parts of the path that I've left out and that vary from drive architecture to architecture. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811151941.LAA13761>