Date: Thu, 13 Dec 2001 04:00:53 +0100 From: Bernd Walter <ticso@cicely8.cicely.de> To: Greg Lehey <grog@FreeBSD.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Wilko Bulte <wkb@freebie.xs4all.nl>, Mike Smith <msmith@FreeBSD.org>, Terry Lambert <tlambert2@mindspring.com>, Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, freebsd-current@FreeBSD.org Subject: Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)) Message-ID: <20011213040053.A20140@cicely8.cicely.de> In-Reply-To: <20011213124753.Q3448@monorchid.lemis.com> References: <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211031120.G11774@cicely8.cicely.de> <20011212162205.I82733@monorchid.lemis.com> <20011212125337.D15654@cicely8.cicely.de> <20011213105413.G76019@monorchid.lemis.com> <20011213030613.A18679@cicely8.cicely.de> <20011213124753.Q3448@monorchid.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 13, 2001 at 12:47:53PM +1030, Greg Lehey wrote: > On Thursday, 13 December 2001 at 3:06:14 +0100, Bernd Walter wrote: > > Currently if we have two writes in two stripes each, all initated before > > the first finished, the drive has to seek between the two stripes, as > > the second write to the same stripe has to wait. > > I'm not sure I understand this. The stripes are on different drives, > after all. Lets asume a 256k striped single plex volume with 3 subdisks. We get a layout like this: sd1 sd2 sd3 256k 256k parity 256k parity 256k parity 256k 256k 256k 256k parity ... ... ... Now we write on the volume the blocks 1, 10, 1040 and 1045. All writes are initated at the same time. Good would be to write first 1 then 10 then 1040 and finaly 1045. What we currently see is write 1 then 1040 then 10 and finaly 1045. This is because we can't write 10 unless 1 is finished but we already start with 1040 because it's independend. The result is avoidable seeking in subdisk 1. Back to the >256k performance breakdown you described. Because of the seeks we have not only unneeded seeks on the drive but also have a different use pattern on the drive cache. Once the locks are untangled it is required to verify the situation as the drive cache may behave differently. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011213040053.A20140>