Rich
I am not aware a specific problem with 6.5 and Mirrored Disk/iX. The problem
you are probably referring to is that when the I/O queue depth exceeds the
time
that an I/O can complete (usually about 1 minute 40 seconds) then the mirror
software believes that the I/O failed and marks one of the disks as Mirrored
Disabled. With one drive the code will wait indefinitely for I/Os to
complete.
When we designed Mirrored Disk/iX disks were in the 600MByte range and the
processor couldn't generate that much I/O traffic to cause these problems.
In MPE/iX release 5.5 we changed the mirror code to not start the 100 second
counter
until the first write completes. This fixes the queue depth balance problem
for writes
but does not solve it for reads and this did solve a great number of
problems.
But as time marches on, we have faster processors able to create more I/O
and the
problem of Disabled Mirrored Disk is slowing reappearing but this time
because the
I/Os are stacking up in the read queue.
When I solved this problem the first time (for writes) I figured this should
hold us for
3 to 4 years before the read timer path would need to be redesigned.
The reference to performance detriment due to waiting for two writes instead
of
one is not true. When we issue the writes they are done asynchronously, we
then
wait for both writes to complete. The over all time is based on the time it
takes
for the slowest disk to complete. We do not issue a write and wait for that
write
to complete before issuing the second write.
The request has made it to the lab but is not marked low priority, it is
just lower than other projects were are working on.
Mirrored Disk/iX was and is still a viable product that solves a customer
need.
I have no intention of obsoleting Mirrored Disk/iX until there is a clear
alternative
solution that user want/need and embrace.
Walter McCullough
High Availability Architect/Manager
BCC, Commercial Systems Division
--------------------------------------------------------
Holloway, Rich <[log in to unmask]> wrote in message
news:9063nl0309q@enews4.newsguy.com...
> Another thing to consider when choosing to have Raid over Mirror/ix is the
> level at which the protection is handled. Raid is handeled at the hardware
> end and Mirror/ix is handled at the O/S end. If you have an application
that
> is write intensive Mirror/ix is actually detrimental to your system
> performance because the O/S has to actually do two writes for every one
> write request. I've heard that for read intensive processes the
performance
> is a wash or Mirror/ix is better. Also with Mirror/ix on 6.5 there is a
> problem with mirrored volumes being dropped if there is a large number of
> disks and large number of I/Os. We have put a fix request to HP and it has
> made it to their lab but has a low priority. Hp has indicated the low
> priority is due to plans to drop the Mirror/ix product.
>
> Rich Holloway
> Providence Health Plans
> Phone (503) 574-7457
>
> The opinions expressed here are strictly mine and do not represent
> anybody else, company, or organization.
>
> "In complete darkness we are all the same. It is only our knowledge and
> wisdom that separates us. Don't let you eyes deceive you." Janet
> Jackson, Rhythm Nation album.
>
>
> -----Original Message-----
> From: Emerson, Tom # El Monte [mailto:[log in to unmask]]
> Sent: Thursday, November 30, 2000 9:17 AM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Mirrored Disk vs. Raid
>
>
> Maybe that's the "key" -- regular PREVENTATIVE maintenance -- we recently
> had a "problem" that PM'ing would have prevented [well, at least I THINK
it
> would have prevented the problem] -- the fan in the power supply of the
disk
> cabinet had gotten so gunked up with dust that it simply stopped working.
> Once it stopped, the power supply "overtemped" and shut off -- as you can
> imagine, a "bad thing" for a power supply to do -- and brought production
to
> a halt... Other than the fact it it physically inaccessible, a quarterly
> vacuuming out of accumulated dust would have prevented the problem [or, at
> the very least, would have shown an indication a problem was developing
well
> enough in advance the fan or supply could have been replaced with minimal
> interruption -- on the good side of things, however, since this was an
> external drive box, and even though these are "system volume set" disks,
we
> were able to leave the system "running" when we replaced the supply, once
> the drives spun back up, everything picked up where it left off...]
>
> > -----Original Message-----
> > From: Bartram, Chris [mailto:[log in to unmask]]
> >
> > If you recall, the MTBF on the old 7933/7935 disc drives was about 13
> > months. When I ran a shop of series 70s, we had CEs in to do
> > PMs at least
> > once a month - most of the work they did was working on the
> > disc drives
> > (changing filters, checking the mechs, etc.)
> >
> > When you compare the amount of data and the MTBF on those old
> > drives (13
> > months/404MBs) to the newer 18+Gb drives, we can't complain
> > too much (not
> > that that stops me... I still lose way to many of the 4.3Gb
> > discs in our
> > production box. ;-) ).
> >
> > -Chris Bartram
>
|
