From owner-freebsd-hackers Fri Nov 13 15:26:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19628 for freebsd-hackers-outgoing; Fri, 13 Nov 1998 15:26:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from news2.du.gtn.com (news2.du.gtn.com [194.77.9.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19617 for ; Fri, 13 Nov 1998 15:26:27 -0800 (PST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely.cicely.de (cicely.de [194.231.9.142]) by news2.du.gtn.com (8.8.6/8.8.6) with ESMTP id AAA05542; Sat, 14 Nov 1998 00:25:27 +0100 (MET) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) by cicely.cicely.de (8.8.8/8.8.8) with ESMTP id AAA03774; Sat, 14 Nov 1998 00:25:28 +0100 (CET) Received: (from ticso@localhost) by cicely5.cicely.de (8.9.0/8.9.0) id AAA00482; Sat, 14 Nov 1998 00:25:23 +0100 (CET) Message-ID: <19981114002523.39363@cicely.de> Date: Sat, 14 Nov 1998 00:25:23 +0100 From: Bernd Walter To: Mike Smith , Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone References: <98Nov13.140613est.40335@border.alcanet.com.au> <199811132150.NAA00549@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199811132150.NAA00549@dingo.cdrom.com>; from Mike Smith on Fri, Nov 13, 1998 at 01:50:40PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Nov 13, 1998 at 01:50:40PM -0800, Mike Smith wrote: > > Greg Lehey 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. Where's the problem with these options on when using Spindle Sync? > > > > 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). That's right - but you can't expect a high linear performance increase when using great stripes. By the way: Is FFS limited to 64k Blocksize? At least newfs can't handle it it my case: root@cicely5# newfs -f 65536 -b 131072 rda14e Warning: 640 sector(s) in last cylinder unallocated /dev/rda14e: 2116992 sectors in 517 cylinders of 1 tracks, 4096 sectors 1033.7MB in 33 cyl groups (16 c/g, 32.00MB/g, 1024 i/g) super-block backups (for fsck -b #) at: 256, 65792, 131328, 196864, 262400, 327936, 393472, 459008, 524544, 590080, 655616, 721152, 786688, 852224, 917760, 983296, 1048832, 1114368, 1179904, 1245440, 1310976, 1376512, 1442048, 1507584, 1573120, 1638656, 1704192, 1769728, 1835264, 1900800, 1966336, 2031872, 2097408, read error: 768 newfs: rdfs: Bad address root@cicely5# newfs -f 65536 -b 65536 rda14e Warning: 640 sector(s) in last cylinder unallocated /dev/rda14e: 2116992 sectors in 517 cylinders of 1 tracks, 4096 sectors 1033.7MB in 33 cyl groups (16 c/g, 32.00MB/g, 512 i/g) super-block backups (for fsck -b #) at: 128, 65664, 131200, 196736, 262272, 327808, 393344, 458880, 524416, 589952, 655488, 721024, 786560, 852096, 917632, 983168, 1048704, 1114240, 1179776, 1245312, 1310848, 1376384, 1441920, 1507456, 1572992, 1638528, 1704064, 1769600, 1835136, 1900672, 1966208, 2031744, 2097280, > > > 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 -- B.Walter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message