Re: Page cleaners and raids
Andrew Hamm wrote: > > On that subject, (and sorry to diverge from what you may understand, Debbie) > can someone clear up a question I've been wanting to ask? With the > split-reads offered by Informix mirroring, does it split the addresses thru > the middle of the total chunk size, or thru the middle of the high-watermark > of the currently allocated space in the chunk? Seems to be it should take > the watermark into consideration, cos if you allocate a 1G space but > currently only load 200M, then you ain't gonna get split reads. My understanding is that it has nothing to do with chunk size, but rather the number of pages to be written. They are sorted by chunk, then into disk order, so that the first half can be written to the primary chunk and the second half to the mirror chunk. This algorithm is very simple, but may well have changed now in version 9.x. It is unlikely that Informix mirroring will beat H/W mirroring that can do load balancing because other access to those disks is taken into consideration. Cheers, -- Mark. +----------------------------------------------------------+-----------+ | Mark D. Stock mailto:mdstock@mydas.freeserve.co.uk |//////// /| | http://www.informix.com http://www.informixhandbook.com |///// / //| | http://www.iiug.org +-----------------------------------+//// / ///| | |This email will self-destruct in |/// / ////| | |10 sec. If you received this email |// / /////| | |in error, sorry about the mess. |/ ////////| +----------------------+-----------------------------------+-----------+
Mark D. Stock wrote in message <91bm23$d5q$1@news.xmission.com>... > >Andrew Hamm wrote: >> >> On that subject, (and sorry to diverge from what you may understand, Debbie) >> can someone clear up a question I've been wanting to ask? With the >> split-reads offered by Informix mirroring, does it split the addresses thru >> the middle of the total chunk size, or thru the middle of the high-watermark >> of the currently allocated space in the chunk? Seems to be it should take >> the watermark into consideration, cos if you allocate a 1G space but >> currently only load 200M, then you ain't gonna get split reads. > >My understanding is that it has nothing to do with chunk size, but >rather the number of pages to be written. They are sorted by chunk, then >into disk order, so that the first half can be written to the primary >chunk and the second half to the mirror chunk. > >This algorithm is very simple, but may well have changed now in version >9.x. It is unlikely that Informix mirroring will beat H/W mirroring that >can do load balancing because other access to those disks is taken into >consideration. > Emm, I was asking about split reads, page 23-9 of the admin guide (V7). You sound like u are saying that writes are also split, but I didn't think that was possible because both chunks MUST be written. Are you implying there is some sort of priorisation going on along the lines of split reads? Can you give a page number? I'm inclined to say the opposite about mirroring winners - I'm talking about a system that is principally doing Informix only (and running the apps, which don't do any serious I/O through file systems). Since the engine submits the two writes asynchronously, then the load balancing in the write queues will allow the two disks to be doing different things. What we need is hard numbers. Can you justify with numbers? From what I've read about RAID, some types will be definitely slower than informix mirroring, but I can see that HW mirroring could have the most chance of out-performing IFX mirrors, depending on quality of the system. What do you think about O/S software mirroring? Crap?
Andrew Hamm wrote: > > Mark D. Stock wrote in message <91bm23$d5q$1@news.xmission.com>... > > > >Andrew Hamm wrote: [SNIP] > >My understanding is that it has nothing to do with chunk size, but > >rather the number of pages to be written. They are sorted by chunk, then > >into disk order, so that the first half can be written to the primary > >chunk and the second half to the mirror chunk. > > > >This algorithm is very simple, but may well have changed now in version > >9.x. It is unlikely that Informix mirroring will beat H/W mirroring that > >can do load balancing because other access to those disks is taken into > >consideration. > > > Emm, I was asking about split reads, page 23-9 of the admin guide (V7). > > You sound like u are saying that writes are also split, but I didn't think > that was possible because both chunks MUST be written. Are you implying > there is some sort of priorisation going on along the lines of split reads? > Can you give a page number? > > I'm inclined to say the opposite about mirroring winners - I'm talking about > a system that is principally doing Informix only (and running the apps, > which don't do any serious I/O through file systems). Since the engine > submits the two writes asynchronously, then the load balancing in the write > queues will allow the two disks to be doing different things. What we need > is hard numbers. Can you justify with numbers? From what I've read about > RAID, some types will be definitely slower than informix mirroring, but I > can see that HW mirroring could have the most chance of out-performing IFX > mirrors, depending on quality of the system. What do you think about O/S > software mirroring? Crap? In their testing, described in an old white paper no longer available, Informix mirror came in a VERY close third behind software mirroring which was a distant second to hardware mirroring. Writes are split to keep both disks equally busy. The halves are written to opposite mirrors then the engine switches and writes the other halves. Art S. Kagel