Hi,
Here is the summary for my hsz question, which follows at the bottom of this
message.
Thanks for resposes from...
alan _at_ dec
Tom Korenek
Robert Carsey
As far as one controller seeing unflushed cache and the other HSZ not seeing
unflushed
cache is even though they are dual redundant, each HSZ takes care of its own
disk units
independently which is the reason why one would have unflushed cache and the
other wouldn't.
As far as the writeback_cache flag, I'll include Alan's e-mail as it expalins it
much
better than I can summarize :-)
thanks,
Allan
____________________________________________________
The RAID-5 implementation on the HS family (and perhaps
some of mirroring as well), uses metadata to keep track
of the state of each disk block. When RAID-5 writes are
started, some of this metadata is changed to indicate
that a write is in progress. When the write completes,
the metadata is cleared.
If a RAID subsystem goes down while writes are in progress,
they need some method to determine whether all the data and
parity was updated correctly. Failure to do this leaves
what's called the "Write hole". If you can't tell which
of the data and parity are consistent and lose a disk
while the subsystem is down, you may regenerate the wrong
data based on bad parity or other contributing data.
The metadata management done by the HS family ensures that
it can at least tell if the parity and data are consistent,
allowing to return an I/O error instead of the wrong data.
If these metadata operations were done directly to disk
(since it has survive a power failures), the subsystem
would be very slow. By using the writeback cache, the
subsystem can maintain reasonable performance even under
heavy write loads to a RAID-5.
But, that's just the metadata. You can also use the
writebache for data writes, which can improve the
performance even more. Whether use of the writeback
cache improves your I/O load, depends on your I/O.
For most reasonable loads it does.
Original question below.....
---------------------- Forwarded by Allan J Simeone/CLV/ClinLabs on 10/20/2000
01:37 PM ---------------------------
Allan J Simeone/CLV/ClinLabs_at_CL on 10/20/2000 10:13:18 AM
To: tru64-unix-managers_at_ornl.gov_at_SMTP_at_QX
cc:
Subject: dual redundant hsz question
Hi All,
This might be a stupid question, but I got some complaints about intermittent
long queue length
on our disks. We already have the load spread out, raid, etc. My question
is focused on the hsz's. I noticed our disk units on the hsz's has
nowriteback_cache
set and I plan to turn that on. Management wants to discuss this before I
enable it so
I need to double check something. We have dual redundant hsz 70's. If I do a
"show this"
on one hsz, it shows no unflushed data in cache. If I do a "show other",
it shows there is
unflushed data in cache.
Is this a problem or is this normal behavior and I'm just catching it in the
inbetween states of the show commands?
Since the disk units has nowriteback_cache set, I'm not sure
where the data in cache is from in the first place.
I don't see any cache policy, but I do see Host Functionality Mode = A.
Cache_flush_timer is set to the default, 10 seconds.
nocache_ups.
32 megabyte write cache, version 4
cache is good
battery is good
Pretty much the same info with Mirrored Cache.
thanks for any info.
Allan
Received on Fri Oct 20 2000 - 17:48:53 NZDT