On 9/14/07, Simon Banton centos@web.org.uk wrote:
I see where you're going with larger journal idea and I'll give that a go.
Have you done any filesystem optimization and tried matching the filesystem to the raid chunk size? A while back Ross had a very good email thread regarding this. Some of the details he went over in the thread are here -> http://wiki.centos.org/HowTos/Disk_Optimization.
It makes a tremendous difference in raid operation.
At 08:09 -0400 14/9/07, Jim Perrin wrote:
Have you done any filesystem optimization and tried matching the filesystem to the raid chunk size?
No, I haven't. This is 3ware hardware RAID-1 on two disks with a single LVM ext3 / partition - I'm afraid I don't know how to go about discovering the chunk size to plug into Ross's calcs.
S.
Simon Banton wrote:
At 08:09 -0400 14/9/07, Jim Perrin wrote:
Have you done any filesystem optimization and tried matching the filesystem to the raid chunk size?
No, I haven't. This is 3ware hardware RAID-1 on two disks with a single LVM ext3 / partition - I'm afraid I don't know how to go about discovering the chunk size to plug into Ross's calcs.
I wouldn't worry about calculations at this point. Everything you described is pointing to bad hardware and not software tuning.
Try getting another identical 3ware card and swapping them. If it produces the same problem, then try putting that card in another box with a different motherboard to see if it works then.
Once the basic card is working then we can talk about getting the maximum performance out of it.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
At 09:41 -0400 14/9/07, Ross S. W. Walker wrote:
Try getting another identical 3ware card and swapping them. If it produces the same problem, then try putting that card in another box with a different motherboard to see if it works then.
I've got three identical machines here - two as yet not unpacked - so I guess I'd better start unpacking another one. Getting hold of a comparable class machine with a different motherboard is going to be tricky though.
It's going to be a busy weekend...
S.
Simon Banton wrote:
At 08:09 -0400 14/9/07, Jim Perrin wrote:
Have you done any filesystem optimization and tried matching the filesystem to the raid chunk size?
No, I haven't. This is 3ware hardware RAID-1 on two disks with a single LVM ext3 / partition - I'm afraid I don't know how to go about discovering the chunk size to plug into Ross's calcs.
You can see the chunk size either in the raid's BIOS tool (Alt-3 at startup) or, if installed, in the 3dm CLI (defaults to 64k, I think).
-- Sebastian
At 15:43 +0200 14/9/07, Sebastian Walter wrote:
Simon Banton wrote:
No, I haven't. This is 3ware hardware RAID-1 on two disks with a single LVM ext3 / partition - I'm afraid I don't know how to go about discovering the chunk size to plug into Ross's calcs.
You can see the chunk size either in the raid's BIOS tool (Alt-3 at startup) or, if installed, in the 3dm CLI (defaults to 64k, I think).
Hmmm, from what I can see in the tw_cli documentation, stripe size (and hence, presumably, chunk size) doesn't apply to RAID 1.
(apologies is the formatting goes awry):
Stripe consists of the logical unit stripe size to be used. The following table illustrates the supported and applicable stripes on unit types and controller models. Stripe size units are in K (kilo bytes).
Model | Raid0 | Raid1 | Raid5 | Raid10 | JBOD | Spare | Raid50 | Single |
------+---------+--------+--------+---------+------+-------+--------+--------+ 9K | 16 | N/A | 16 | 16 | N/A | N/A | 16 | N/A | | 64 | | 64 | 64 | | | 64 | | | 256 | | 256 | 256 | | | 256 | |
------+---------+--------+--------+---------+------+-------+--------+--------+
I'm focused now on swapping the card for a fresh one to see if it makes any difference, as per Ross's suggestion.
S.
Simon Banton wrote:
At 15:43 +0200 14/9/07, Sebastian Walter wrote:
Simon Banton wrote:
No, I haven't. This is 3ware hardware RAID-1 on two disks with a single LVM ext3 / partition - I'm afraid I don't know how
to go about
discovering the chunk size to plug into Ross's calcs.
You can see the chunk size either in the raid's BIOS tool (Alt-3 at startup) or, if installed, in the 3dm CLI (defaults to 64k, I think).
Hmmm, from what I can see in the tw_cli documentation, stripe size (and hence, presumably, chunk size) doesn't apply to RAID 1.
Some cards do, some cards don't. I suppose the idea is by chunking the data in a RAID 1 the logic on the card can be the same between a RAID1 and a RAID10 (just a 2 drive RAID10) and therefore can save R&D money and NVRAM costs due to smaller firmware.
(apologies is the formatting goes awry):
Stripe consists of the logical unit stripe size to be used. The following table illustrates the supported and applicable stripes on unit types and controller models. Stripe size units are in K (kilo bytes).
I'm going to guess that it is not configurable, but 3ware uses 64k chunk size on RAID1 simply for the cost savings mentioned earlier.
It will have 0 performance impact either way.
I'm focused now on swapping the card for a fresh one to see if it makes any difference, as per Ross's suggestion.
Well I should have said try on another identical machine too in case there is something off on this one, and since you have 2 others and time to kill until a different model machine arrives...
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.