| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1045.1 | | 29067::BUTTERWORTH | Gun Control is a steady hand. | Tue Oct 17 1995 18:39 | 7 |
| There is no canned way to do this. Does the customer archive
frequently? I ask because Archive works by saving the archived data
to the archive area and then overlaying the "kept" data onto the
existing file and then we truncate the remainder.
Regards,
dan
|
| 1045.2 | Should be ok, but raid 5? | 61017::TSG_TAS | Mr Mass | Wed Oct 18 1995 00:52 | 21 |
| We've been at 99.9 for ages, can't quite get that extra .1! But in thinking
about it the real downside to fragmented disks is reading them. PCM (if the disk
is only used for this) is just about 100% write. If you're concerned you could
increase the rms extend amount which should reduce a bit of xqp overhead in
creating extended headers - perhaps.
How does your raid 5 set perform? We're in the process of setting PCM up on
another machine and I had intended creating the logfiles volume out of a couple
of host based shadowed rz29s. Someone else suggested a 5 member controller based
raid 5 set. I was concerned that it would be too slow.
Our normal lpm is about 1500, but a 2 node cluster reboot can get this over 8000
lpm. Two 3 node cluster reboots would be interesting, and a datacenter reboot
out of this world. A tiny bit of testing showed that the shadowset had a
sustained i/o queue (ok, an o queue) of 2 when 27000 average length lines per
minute was thrown at it. We might expect a raid 5 set to be a lot slower in the
0-20% reads which doesn't help my concern. We are currently waiting on hsz
writeback cache batteries to test the raid 5 set, but any prior experience would
be interesting.
Tony Sherrard
|
| 1045.3 | | 52336::STRATMAN | Peter Stratman @VBO | Mon Oct 30 1995 06:58 | 16 |
| re. .1
No the customer doesn't archive, yet. I'm not sure I understand; do you
mean that archiving fragments disks, or that on the contrary, it might
help ?
re. .2
This customer's lpm is WAY less than what you're talking about, so
there's no performances at all.
Conclusion: only way to get around this is to increase the file
extension value on the volume.
|
| 1045.4 | | 29067::BUTTERWORTH | Gun Control is a steady hand. | Mon Oct 30 1995 16:52 | 7 |
| Potentially, it could fragment the disk due over a period of time.
certainly the extend quantity could help.
Regs,
dan
|
| 1045.5 | | 61017::TSG_TAS | Mr Mass | Mon Nov 06 1995 00:57 | 11 |
| Folks
If you don't do much io to this volume is the fragmentation a problem, or merely
a question of aesthetics? If there is no problem there is little need to try to
fix it (though I agree that this shouldn't preclude proper care and attention).
If you were to have large archives (it sounds as though you won't) they might be
made quicker by less fragmented disks - that's all
FYI the RAID 5 set handled high ios with aplomb - never put a head wrong.
Tony Sherrard
|
| 1045.6 | | 29067::BUTTERWORTH | Gun Control is a steady hand. | Mon Nov 06 1995 10:30 | 13 |
| >If you don't do much io to this volume is the fragmentation a problem,
>or merely a question of aesthetics?
I agree in the case of the archive volume but the original question was
in regard to one of the active logging volumes. In the past I had
highly fragmented volumes degrade logging performance - yes, these
disks were quite chopped up and the effect on logging performance was
enough to notice. Of course reading them was absolutely pathetic as
expected.
Regs,
Dan
|