Date: Sat, 14 Nov 1998 22:51:17 -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: <199811150651.WAA10105@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 14 Nov 1998 23:40:53 GMT." <199811142340.QAA27778@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> [ ... disk-to-disk copies over the SCSI bus not involving the host ... ] > > > > > And it's almost impossible to find > > > >spindle synchronized disks nowadays. > > > > > > Seagate Barracuda's support it, I assumed that the newer Seagates did > > > as well. The impression I got was that all you had to do was wire the > > > `spindle sync' lines from all the disks together and then designate > > > all except one as a sync'd slave. Admittedly, I've never tried > > > actually using it. > > > > Most modern "server class" SCSI disks support it. It's not useful > > unless you turn off tagged queueing, caching and most other drive > > performance features. > > 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. > Bringing a new disk online in a RAID 5 array could also use this > to advantage. What you want is the SCSI COPY command. > Finally, if a disk could be made to talk to itself (unlikely, but > some vendor probably neglected to prevent it by checking for the > same source/target ID, I hope 8-)), it would be useful for various > intra-disk transfers of data, as well. This is beyond far-fetched. > > You'd have to cons a new map and have it present the scattered target > > area as a linear region. This is expensive, and the performance boost > > is likely to be low to nonexistent for optimal stripe sizes. > > Concatenation of multiple stripe reads is only a benefit if the stripe > > is small (so that concatenation significantly lowers overhead). > > Compared to the normal recalculation time on a new hot-swap on a > large array, I would think that even though it's expensive, it > would be less expensive than the alternative of having to do the > same thing anyway, *and* transfer the SCSI data in an out of host > memory over, best case, a PCI bus. This has nothing to do with array reconstruction. Having just watched Event Horizon, I can imagine how your brain got here, but you're completely crossed up. Go back. > > > What would be useful is some help (from vinum or ccd) to ensure that > > > the cylinder group blocks (superblock + inode maps etc) don't cross > > > stripes. > > > > That's something that the user should take care of. Any power-of-2 > > stripe size is likely to work out OK, as CG's are currently 32MB. > > Hm. Maybe the tools should limit this, or at least "bitch", in the > same sense that disklabel puts up little asterisks... Disklabel should stop putting them up. They're not meaningful anymore. It's arguable as to whether it actually matters whether CG's fragment across stripe boundaries either. -- \\ 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?199811150651.WAA10105>