Date: Thu, 23 Jul 1998 14:34:26 +0930 From: Greg Lehey <grog@lemis.com> To: Mikhail Teterin <mi@aldan.algebra.com> Cc: questions@FreeBSD.ORG Subject: Re: ccd questions Message-ID: <19980723143425.T8993@freebie.lemis.com> In-Reply-To: <199807230447.AAA05997@rtfm.ziplink.net>; from Mikhail Teterin on Thu, Jul 23, 1998 at 12:47:19AM -0400 References: <19980723133831.P8993@freebie.lemis.com> <199807230447.AAA05997@rtfm.ziplink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 23 July 1998 at 0:47:19 -0400, Mikhail Teterin wrote: > Greg Lehey once stated: > >>> I'm trying to do this under a day old -stable. There are four disks >>> -- 2 2Gb and 2 4Gb -- involved. I set up two ccd mirroring disks >>> 2Gb and 4Gb big each with different ileave numbers (from 2 to 6000, >>> being powers of 2 and primes). Here are my problems: > >>> The 4 disks are on an ahc of their own with an idle tape-drive. I >>> never tested both arrays at the same time. The 3 system disks are >>> on a separate ahc. The machine has a single PPro-200 with 256Kb of >>> cache, 128Mb of RAM, 192Mb of swap split evenly among three system >>> drives. > >>> All four disks are different, so I do not expect "optimum" >>> performance, but my results were still disappointing :( >>> >>> According to iozone benchmark, the write speed went down 50% >>> compared to when using the disks by themselves -- without >>> ccd. I would expect it to stay the same, really -- it is >>> about 3.5Mb/sec and is far from saturating the 10Mb/s top >>> of this SCSI interface. The ileave number does not seem to >>> matter once it is above 32. > >> Yes, I'd consider this result disappointing as well. May I assume >> that the performance improved with increasing the ileave factor? My >> investigations suggest that 128 is about the optimum, though there's >> not much improvement beyond 32. > > Yes, it grows, but very little... And is always 50-60% of the single > disk speed. > >>> The read speed is about the same -- according to `systat 1 >>> -iostat' the data is read only from the first disk of an >>> array -- I'd expect it to double as the things can be read >>> in parallel from each of the drives. Again the ileave number >>> does not seem to matter once it is above 32. > >> This would only happen if you're runnning multiple processes. >> Otherwise you'll be single-threaded by the test. > > Khmmm... Why is not it reading, say 10% of a file from one disk and > the next 10% from the other, in parallel? No buffers, I guess... Oh, > well... Because you've increased the interleave size to where most requests can be satisfied by one disk. As you've observed, this is an advantage, not a disadvantage. The main delay in disk transfers is latency, not transfer time, and transfer time is the only thing you gain on by splitting a request this way. >>> Features/stability: >>> >>> I tried to create the third ccd to concatenate the two >>> mirroring disks into one 6Gb big chunk. It "did not work" >>> most of the time, and crashed the system once when it seemed >>> to succeed and I started to >>> newfs /dev/rccd2c >>> Is this combination supposed to work at all? > >> I'm not sure what you're trying to do here. What does your >> /etc/ccdconfig look like? Are you trying to join ccds together into >> second-level ccds? I don't see any reason to want to do this, and I'm >> pretty sure nobody expects it to work. In any case, when you have such >> problems, there's little anybody can do without a kernel dump. > > Yes, it is like this: > ccd0 2047 0x05 /dev/sd3s1e /dev/sd5s1e > ccd1 6000 0x05 /dev/sd4s1e /dev/sd6s1e > ccd2 0 none /dev/ccd0c /dev/ccd1c I would strongly discourage this configuration. Even if it were to work (and it looks as if it doesn't), you could run into horrendous kernel buffer allocation problems. > The reason is to have a system which can be quickly brought back > up in case of a drive failure (any one of the 4 disks can go, even > two different ones can go), while providing one big partition for > a big file-system. It's relatively trivial to achieve this result with vinum. I don't know whether you could use a different ccd configuration to achieve it--I think the difference in size of the ccds would probably be a problem. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980723143425.T8993>