Some of the new 1TB Seagate drives come shipped with a 1.5GBps jumper enabled by default. The ST31000340AS drive has a jumper on the back that needs to be removed to enable 3.0GBps transfer. This "jumper secret" may also apply to Seagate drives so make sure to double check your existing and new Seagate drives for this limitation.
Directly from Seagate’s manual:
Serial ATA drives are designed for easy installation. It is usually not necessary to set any jumpers on the drive
for proper operation; however, if you connect the drive and receive a “drive not detected” error, your SATAequipped
motherboard or host adapter may use a chipset that does not support SATA speed autonegotiation. If
you have a motherboard or host adapter that does not support autonegotiation:
•Install a jumper as shown in Figure 3 below to limit the data transfer rate to 1.5 Gbits per second (and leave the drive connected to the SATA-equipped motherboard or host adapter that doesn’t support autonegotiation) or
•Install a SATA host adapter that supports autonegotiation, leave the drive jumper block set to “Normal operation” (see Figure 3 below), and connect the drive to that adapter. This option has the benefit of not limiting the drive to a 1.5 Gbits/sec transfer rate.
The only issue is that the jumper comes pre-installed on these drives in particular.
Good luck and happy hard disking!
I’ve met and spoke with quite a few persons who believe that RAID is the answer to all of their data-safety needs. There is only one thing I can say about relying solely on RAID: “It’s a horrible idea!”. RAID is a good supplemental protection mechanism in your entire data integrity plan but it is not THE answer.
- RAID is usually susceptible to double-disk RAID faults. While this may not sound like a normal or even conceivable possibility it is a very real issue that I have personally experienced. RAID-6 offers some higher levels of protection to this problem. Most new 9600 series 3Ware controllers (and most newer controllers) offer RAID-6 capabilities. Choose a RAID-6 able card and, if possible, always run a BBU (Battery Backup Unit).
- RAID will never protect against file corruption or viruses.
- RAID can’t protect against human error. We’re all human, we all make mistakes. If you just hit the delete key on an entire directory of your company’s data then you can probably hit the delete key on your job as well. This is why backups, along with RAID, is the best data integrity solution.
- RAID will only protect you if you are proactive. Some lower quality RAID controllers do not send email alerts and do not properly alert you of an issue. These controllers require special attention. The more user interaction is needed the less likely you will notice a fault. Having a hot spare or spare disks available for swapping is always a good idea.
- RAID will not facilitate off-site and disaster recovery scenarios. There are some utilities out there that provide block-level replication.
In summary, the best data integrity plan is to use RAID to supplement your plan. Don’t rely on RAID as your sole backup/data security mechanism. I personally recommend using RAID-6 with a block-level backup of all data to an off-site location. Using software like R1Soft’s CDP will allow for full block-level backups and file-level and bare-metal restores. Remember to always double check your data integrity plan and never be satisfied with your solution! I personally hate loosing data. With drives as cheap as they are today, why aren’t you backing up offsite?
Ever wondered what was going on with a server or desktop that just wasn’t performing “right”? Sure the load average is a good representation of the overall load as described here, but, how do you track down the actual source of the issue? Try out these five utilities to help you track down any load-related issues with your Linux-based installation.
Yes, that’s right, good ol’ fashioned “top”. If you haven’t already used the top command then you may not have been using Linux that much. Top provides a real-time look at processor time, processes that are using high amounts of memory/CPU and also an overview of physical and swap memory. A preview of top can be seen to the right. Press “1” to show all CPU’s available (if running multiple-core processors or HT-enabled processors).
There are also other top variants out there which can provide more information in the same “top-like” format. Enter htop. Htop has been around for quite some time and has, as far as I know, gone generally unknown around the Linux world. htop provides colorful (who doesn’t like colors?) views of the system state and shows tree views for processes that provide even more detail. A screenshot of the htop interface can be seen on the right. Obtain more information about htop here.
Got disk performance issues? Find out with iostat! iostat is used for monitoring speed, ops/sec and cpu time spent waiting on input/output devices to respond. This command is quite useful when attempting to see what is causing your load averages to spike. If your system has high i/o wait times you may consider purchasing faster disks or tuning the performance of your application to be less disk-intensive. Performance tuning, for instance, of a MySQL database can greatly decrease the amount of disk i/o needed. Adding indexes and re-constructing queries can speed up MySQL systems that have high i/o wait times. Of course, you can always throw hardware at the issue as well. For more information on iostat see this article.
Direct from the vmstat man page: “vmstat reports information about processes, memory, paging, block IO, traps, and cpu activity.” The data shown in vmstat is the average since last reboot.
Direct from man page:
r: The number of processes waiting for run time.
b: The number of processes in uninterruptible sleep.
swpd: the amount of virtual memory used.
free: the amount of idle memory.
buff: the amount of memory used as buffers.
cache: the amount of memory used as cache.
inact: the amount of inactive memory. (-a option)
active: the amount of active memory. (-a option)
si: Amount of memory swapped in from disk (/s).
so: Amount of memory swapped to disk (/s).
bi: Blocks received from a block device (blocks/s).
bo: Blocks sent to a block device (blocks/s).
in: The number of interrupts per second, including the clock.
cs: The number of context switches per second.
These are percentages of total CPU time.
us: Time spent running non-kernel code. (user time, including nice time)
sy: Time spent running kernel code. (system time)
id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.
wa: Time spent waiting for IO. Prior to Linux 2.5.41, shown as zero.
Although the ps “process list” command does not show real-time updates it can provide useful information as to why your system may be slow. I typically use the “aux” options that shows enough detail but also adding “ww” to the end of “aux” yeilds good results for long commands. Run “ps aux” and look for multiple processes. This is good for troubleshooting if a process like Apache or Exim have spawned many children and caused the system to slow. Use the “e” flag to show children in a tree format.
"A new server for mid-size companies, the Power 560 Express, is due on Nov. 21. It uses a 3.6Ghz Power6 processor, comes in four-, eight- and 16-node configurations, and packs a hefty 384GB of memory. It’s designed for companies looking to run multiple applications on a virtualized system. It will be offered with Linux, AIX or i."
IBM brings a new line of processors and machines to the market with unreal memory capacities.
Apparently one of Facebook’s founders, Dustin Moskovitz, is proverbially “jumping ship” to start his own Internet company. This quite possibly the best move for him. I’ve known many people who specialize in starting large companies and keep moving. I believe this is the true way to make money when it comes to entrepreneurial endeavors.