Date: Fri, 13 Nov 1998 13:50:40 -0800 From: Mike Smith <mike@smith.net.au> To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> Cc: hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone Message-ID: <199811132150.NAA00549@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 13 Nov 1998 14:06:39 %2B1100." <98Nov13.140613est.40335@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Greg Lehey <grog@lemis.com> wrote: > > 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. > > Finally, aggregating involves a > >scatter/gather approach which, unless I've missed something, is not > >supported at a hardware level. Each request to the driver specifies > >one buffer for the transfer, so the scatter gather would have to be > >done by allocating more memory and performing the transfer there (for > >a read) and then copying to the correct place. > > Since the actual data transfer occurs to physical memory, whilst the > kernel buffers are in VM, this should just require some imaginative > juggling of the PTE's so the physical pages (or actual scatter/gather > requests) are de-interleaved (to match the data on each spindle). 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). > 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. -- \\ 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?199811132150.NAA00549>