Date: Sun, 10 Feb 2002 12:35:10 -0800 From: Greg Lehey <grog@FreeBSD.org> To: Tim Baird <tim@techvalley.ca> Cc: questions@FreeBSD.org Subject: Re: Vinum strangeness Message-ID: <20020210123510.D4992@sydney.worldwide.lemis.com> In-Reply-To: <4.2.0.58.20020203022911.009418b0@pop3.norton.antivirus>; from tim@techvalley.ca on Sun, Feb 03, 2002 at 02:39:12AM -0800 References: <4.2.0.58.20020202165607.009dccb0@pop3.norton.antivirus> <4.2.0.58.20020202030832.0094a820@pop3.norton.antivirus> <4.2.0.58.20020202030832.0094a820@pop3.norton.antivirus> <4.2.0.58.20020202165607.009dccb0@pop3.norton.antivirus> <20020203123017.I2189@wantadilla.lemis.com> <4.2.0.58.20020203022911.009418b0@pop3.norton.antivirus>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 3 February 2002 at 2:39:12 -0800, Tim Baird wrote: > At 12:30 PM 03/02/02 +1030, Greg Lehey wrote: >> On Saturday, 2 February 2002 at 17:04:28 -0800, Tim Baird wrote: >>> As per your request for a little more info.... >>> on-disk config... >>> >>> IN VINOvinum1H<*L<V}volume usr state up >> >> Hmm. That "vinum1" is a drive name. That's why it couldn't rename it >> alpha, but I don't understand that. I'll try to reproduce that one. >> Try copying zeros to the disk: >> >> # dd if=/dev/zero of=/dev/ad0s1f count=2 seek=8 >> >> That should transfer two blocks, and after that you should have no >> information from the output dump. Check that I'm right with the >> output device name. > > That seemed to do it.... > > BTW, I am attempting some crude performance tests...basically read/write > speeds using the 4.5 source distribution as a bundle of files to push > around. So far it is about 20% faster when doing a cp from one directory > to another on the non-vinum partition than the equivalent cp between > directories on the vinum partition. I have softupdates enabled on both > partitions. > > There is one fly in the ointment in that the smaller drive (one of the > subdisks of 2G) is a UDMA 33 and the other (which holds 1 2G subdisk and > the remaining non-vinum partions) is a UDMA 66. > > The improved bus transfer rate will still help vinum I suppose when using > the faster subdisk.... > > The bottom line is, am I justified in expecting to see a higher throughput > on the vinum area than the non-vinum area or are there simply too many > other latency factors that I am ignoring? You should see approximately the same performance under these circumstances. If your stripe size is too small, or it's a power of 2, you'll probably see a drop. In the case of too small a stripe size, this is because of the additional I/O that small stripes create. In the latter case, you're going to be hitting the same drive all the time for the metadata updates. It's possible that there are other issues. It would be nice to see what the performance is like on a concatenated plex. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers 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?20020210123510.D4992>