Questions about 3Ware 7506 controller
I'm running 4.7 Release on a colocated system without access to bios/console. This system currently has a Highpoint RocketRaid 100 controller driving four WD 60gb (WD600JB, 8mb cache) drives in a raid 0+1 config. I had a drive fail and the controller kept the system up and functioning, but something has prevented rebuild from occurring, even in the bios utility after replacing the failed drive. HighPoint tech support, while quick to answer the phone, has provided no guidance in the last two weeks. As this is a most inconvienent situation I'm considering replacing the raid controller with a 3Ware 7506-4LP controller so I have more reliability control from the OS level. My two questions are: -What driver/firmware should I use? I have a 3Ware 6410 running in another 4.7 system and am able to use the 3DM utils out of ports to monitor it. I don't know if those utils support the 7506. 3Ware has a beta driver and command line utils for the 7506 and FreeBSD 4.8. Which way to go, 3ware driver or native FreeBSD driver? -Raid 10 or 5? Compared to the 0+1 I have now, 10 would be a nice improvement as loss of the one drive effectively took out two of my drives. Raid 5 would give me an extra 60gb to use, but I don't have any idea what the performance differential would be. Has anybody run bonnie or some such test against a 7506 with raid 5 in FreeBSD? Any thoughts or comments would be appreciated. Thanks, Alvin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: vinum concatenated raid setup problems - SOLVED
I see this has been solved, but i'll throw one more gotcha to watch for out there. Use of 'vinum saveconfig' is a good thing. From the vinum man page: saveconfig Save the current configuration to disk. Normally this is not necessary, since vinum automatically saves any change in configu- ration. If an error occurs on startup, updates will be disabled. When you reenable them with the setdaemon command, vinum does not automatically save the configuration to disk. Use this command to save the configuration. As I was learning to use vinum I made frequent mistakes, disabling updates, then built the system, rebooted, and nothing survived ;) Had to rtfm a couple of times before I caught that. Alvin > Mike, > Thanks for the pointers on the fstab file, they solved that part of the > puzzle. (and trying to help with the other issues) > > Greg, > Thanks for pointing me to the right part of the vinum manpage...it was > indeed the simple fact that I was trying to build the configuration on > disk's rather than partitions that was sabotaging the mission! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Backup over the internet.
I've been using a program called rdiff-backup ( http://rdiff-backup.stanford.edu/ ), based on librsync. This package creates a mirror of your server (or any portion thereof) on a remote server, and keeps track of changes. It only sends changes (ie diff) across the wire, including binaries, so after the initial copy it's pretty bandwidth efficient. It's not in ports ( or wasn't recently ) and takes a little extra work to build it, but IMHO it's well worth the effort. Alvin Gunkel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interface Errors
Opps, forgot to mention that the collisions were a result of mismatched duplex settings. The switch and system are now hardcoded to 10mb full duplex and the number of collisions has not risen since. Alvin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Interface Errors
I am seeing an increasing number of inbound errors on one of my systems. There are no errors indicated on the cisco switch the system is connected to. I get about 250 errors a day. There are no errors indicated on any other other lines from the 'netstat -ib' command, the output of which is below: Name Mtu Network AddressIpkts Ierrs Ibytes Opkts Oerrs Obytes Coll sis0 1500 00:0a:e6:xx:xx:xx 1050392 1083 276417216 547475 0 124967248 5784 'netstat -ss' gives: [kosh:root /]$netstat -ss tcp: 1369978 packets sent 1110237 data packets (259598386 bytes) 4489 data packets (4558958 bytes) retransmitted 189167 ack-only packets (64881 delayed) 50239 window update packets 15961 control packets 1373018 packets received 983065 acks (for 259466635 bytes) 25411 duplicate acks 971899 packets (363304302 bytes) received in-sequence 903 completely duplicate packets (339224 bytes) 7 packets with some dup. data (3355 bytes duped) 14645 out-of-order packets (12898728 bytes) 1795 window update packets 194 packets received after close 327 discarded for bad checksums 5379 connection requests 6597 connection accepts 38 bad connection attempts 11787 connections established (including accepts) 12002 connections closed (including 780 drops) 1906 connections updated cached RTT on close 1906 connections updated cached RTT variance on close 394 connections updated cached ssthresh on close 176 embryonic connections dropped 976748 segments updated rtt (of 852139 attempts) 887 retransmit timeouts 10 connections dropped by rexmit timeout 365 keepalive timeouts 361 keepalive probes sent 4 connections dropped by keepalive 102144 correct ACK header predictions 332038 correct data packet header predictions 6665 syncache entries added 117 retransmitted 97 dupsyn 6597 completed 58 reset 9 stale 1 unreach udp: 62007 datagrams received 111 with bad checksum 129 dropped due to no socket 61767 delivered 64066 datagrams output ip: 1499389 total packets received 32 bad header checksums 14 with incorrect version number 1441915 packets for this host 196 packets for unknown/unsupported protocol 1 packet not forwardable 1442208 packets sent from this host 115 output packets dropped due to no bufs, etc. icmp: 129 calls to icmp_error Output histogram: echo reply: 6890 destination unreachable: 129 Input histogram: destination unreachable: 195 echo: 6890 time exceeded: 1 6890 message responses generated ICMP address mask responses are disabled igmp: Interface is onboard: sis0: port 0xc400-0xc4ff mem 0xcfffc000-0xcfffcfff irq 11 at device 3.0 on pci0 I have several other systems with similar configurations that have never shown any errors like this. The system is colocated, so I don't have easy access to swap cables, switch ports etc. Any idea what could be causing this? Thanks, Alvin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message