Date: Wed, 11 Nov 1998 04:06:54 +0100 From: Bernd Walter <ticso@cicely.de> To: Greg Lehey <grog@lemis.com>, Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone Message-ID: <19981111040654.07145@cicely.de> In-Reply-To: <19981111103028.L18183@freebie.lemis.com>; from Greg Lehey on Wed, Nov 11, 1998 at 10:30:28AM %2B1030 References: <199811100638.WAA00637@dingo.cdrom.com> <19981111103028.L18183@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 11, 1998 at 10:30:28AM +1030, Greg Lehey wrote: > On Monday, 9 November 1998 at 22:38:04 -0800, Mike Smith wrote: > > > > Just started playing with Vinum. Gawd Greg, this thing seriously needs > > a "smart" frontend to do the "simple" things. > > Any suggestions? After seeing people just banging out RAID > configurations with GUIs, I thought that this is probably a Bad > Thing. If you don't understand what you're doing, you shouldn't be > doing it. > > The four-layer concepts used by Veritas and Vinum have always been > difficult to understand. I'm trying to work out how to explain them > better, but taking the Microsoft-style "don't worry, little boy, I'll > do it all for you" approach is IMO not the right way. > :) [...] > > You shouldn't really be doing performance testing in this version. > It's full to the gunwhales of debugging code. But I'd be interested > to know how long it took to do a newfs on one of the disks without > Vinum. > I havn't measured the time but in my opinion it's similary to ccd. Can't say about the disks itself. Looks much like it's faster than ccd together with cam on a striped volume when having parallel access and having not to small stripes. One point is that is doesn't aggregate transactions to the lower drivers. When using stripes of one sector it's doing no more than one sector transactions to the HDDs so at least with the old scsi driver there's no linear performance increase with it. That's the same with ccd. > > There was an interesting symptom observed in striped mode, where the > > disks seemed to have a binarily-weighted access pattern. > > Can you describe that in more detail? Maybe I should consider > relating stripe size to cylinder group size. > I always saw the same and I'm shure that the cylinder groups are mostly placed on one disk each. > > It will get more interesting when I add two more 9GB drives and four > > more 4GB units to the volume; especially as I haven't worked out if I > > can stripe the 9GB units separately and then concatenate their plex > > with the plex containing the 4GB units; my understanding is that all > > plexes in a volume contain copies of the same data. > > Correct. I need to think about how to do this, and whether it's worth > the trouble. It's straightforward with concatenated plexes, of > course. > In my opinion it worth. Concatenation is the only way to increase a partition and it's realy usefull to be able to do on a stripe. I never checked if it's possible to do a stripe on differend sized disks as ccd can do. And ccd is more integrated into the rest of the system but the other things are working at least as good as with ccd. > > Can you nest plexes? > > No. > > > Anyway, apart from one incident where I managed to get a pile of > > debugger calls out of Vinum (freeing already free memory - it > > occurred after many failed config attempts and I haven't been able > > to reproduce it) > > If you do get it again, please don't hesitate. Take a dump. I'd like > to find these problems. > > Having said that, I've been planning to rewrite the config code for a > while. It's still a while off, but in the meantime please tread > carefully. > > > it hasn't let me down yet. Tomorrow I build the world on it. > > Good to hear. I've built several worlds, including with degraded > plexes, and so have others. I don't think you'll have any trouble > there. > No failure with recent versions - at least no obviously. Never observed for memory-probs. > > Thanks to Greg and the folks at Cybernet! I also have to thank all them - it's grown to a usefull software. > > You're welcome. > > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981111040654.07145>