It is hard for me to believe that no one posting has yet understood the question. The issue is that the querent has failed piece of hardware, under warranty, but doesn't want to return it for replacement fear that the data could be recovered by a highly motivated party.
The answer seems clear. Even if you hard a piece of equipment to erase a drive's contents, you would not be able to verify that the erasure has occurred without the drive functioning in the first place. Therefore, there is unlikely to be a satisfactory solution.
Perhaps you would be better served by writing data to the drives in an encrypted form. Thus, after a future failure, under warranty or not, you could be confident that data recovery would be unlikely.
It's been running my raid for a couple of years...I think. I cannot honestly remember when I first configured it.
There are some things to be aware of. If you want to mount / as a raid, it can be tricky. The initrd needs to be properly configured, or the drivers must be built into the kernel.
Sometimes, the raids don't shut-down completely. I've never been able to completely solve this problem. Most of the time it's OK, but some machines have trouble. The most common culprit has been NFS.
GRUB & LILO need some special care when you plan to mount root from a raid mirror. It does work and it has all of the appropriate relibility features.
There are situations where median is the most appropriate measure of average. Take the Bush tax-cut for rich Americans. He stated that on average, Americans would receive a several thousand dollar break in their taxes. His number is correct when calculated as a mean. Using similar logic, you would say that when Bill Gates walks into a bar, the average income of the patrons rises by millions of dollars--I hope you agree that this is a pointless use of the mean. On the other hand, if Bush has been more honest and said that the tax break for the median American was closer to zero dollars, he'd have been much more true to the effect of his program. His tax-cut overwhelmingly affected the highest income earners which is attested by the fact that there is a new tax refund form for refunds over one million dollars.
"You look at this blob on the ground and say, 'There goes our ancestor,' " he said. -- writes Penelope Debelle.
She ought to read Stephen Jay Gould's work before writing about science. Her statement, in fact, is very much wrong. The common supposition that there is a steady march from simple forms to more complex ones is well debunked by Gould. There is plenty of evidence that the same morphology has been developed by several species. Some survive. Others are pruned. Likewise, there is no reason to believe that this creature is an ancestor of modern chordates.
Their system is based on someone else's work. I forget who. It's called a CardEngine. The CPU card is bit larger than a credit card. There's ethernet, CF slot, audio, and it supports TFT. The board is about $250.
A large percentage of the problems were incomprehensible to me. 'Perhaps,', I thought, 'things have changed a lot since I was an undergraduate.' I showed some examples to a local university professor. He couldn't make sense of the questions either.
I'm told that few graduate CS programs require it.
I work with hardware designed for extreme temperatures. As far as I can tell, these are the prime considerations.
1) Mechanical failure due to thermal expansion and contraction. This tends to affect connectors and plugs. Systems with poorly affixed memory components sometimes experience problems.
2) Dissipation of excess heat. A modest external temperature of 35C may produce a temperature in your trunk of over 45C. At 45C, the CPU will have a hard time dissipating heat since heat diffusion requires a gradient. CPUs may tend to fail around 55C.
3) Condensation. As you open and close the trunk in cooler weather, you'll be adding moisture to the closed space. Like dew, moisture will condense out of the air as components cool. Moisture on electronics tends to be less than optimal.
4) Vibration. Automobiles are notoriously hard on electrical components because of the constant vibration. Single strand wire tends to fatigue. Connectors shake loose. There are mounting methods for abating shock and vibration.
The systems we use for extreme temperatures do not sport contemporary CPUs because of the heat problems. To cope with condensation, we place desiccants inside the enclosures.
OK. I'll be more specific. Note that this comes from Alteon who helped me diagnose the 'feature' and make the system work. You have a router on port 1 and a host on port 3 that is being load-balanced. There is a VIP that balances load to your host. It accepts requests through the router on port 1. If the switch is *not* a router, then the default gateway to the host has to be another routing device, in this case, the router on port one. A request on the VIP enters through the router, hits the switch, and is selected for processing by the host. The switch sends the packet to the router via layer 2 which means that the arp cache on the switch will bind the MAC address of the router to the IP address of our destination host. The router wants to send the packet the the host, so it sends it back to the switch. The switch attempts to send it back to the router and voila, the packet is dropped. The problem is with the interaction between the layer 2 switching and the layer 3 (which some people call layer 4) routing. By making the switch understand the local route and therefore capable of being the gateway, the arp cache properly points to the port with the host on it. Please keep in mind that I didn't have any specific gripes with Alteon until I came to configure our production network with all of the hosts running. This routing problem wasn't really serious except that is was a hidden consequence of the Alteon design. We did make it a router, but that meant we had to keep it up to date. I preferred to put the routing in a real router since that's what they're designed to do. Routing on the Alteon is second-class to the rest of the features.
Before anything else, I laud the Slashdot team for quickly resolving their network access problems. I've been through something similar and can appreciate the complexity of diagnosing these problems.
..
I spent a statistically average stint deploying servers at exodus for an ecommerce site. I had a couple of odd experiences that I could not completely explain.
First, I, too, received 10/24 packets from the Exodus network that Exodus denied could be coming through their routers. I was using a simple 2600 series router with ACLs to do my filtering/firewalling, so it was quite clear where the packets came from.
I worked with three different load-balancing devices including the F5 and the Alteon Networks devices. None of them met my evaluation criteria of sufficient features and believable reliability. I bought the Alteon device because I could make it work within four hours and it appeared to have the right features. Then, the trouble ensued. The device failed us, under a very meager load, not because it wasn't fast enough, but because the features of the device interact in very complex ways. The fundamental problem is that the mixture of a switch, router and load-balancer in once device doesn't agree with IP. ITOT, we had to use it for all three even though we had a router that we preferred to use as...a router, dummy.
Lastly, we used a Debian GNU/Linux box as a gateway through the firewall using the cipe VPN code. This was the most reliable piece. Although, to be fair, it wasn't maintenance free. There were times with the VPN link would drop without explanation. Fortunately, we never lost contact with the box and so we could always nudge the link.
Slashdot Mirror
It is hard for me to believe that no one posting has yet understood the question. The issue is that the querent has failed piece of hardware, under warranty, but doesn't want to return it for replacement fear that the data could be recovered by a highly motivated party.
The answer seems clear. Even if you hard a piece of equipment to erase a drive's contents, you would not be able to verify that the erasure has occurred without the drive functioning in the first place. Therefore, there is unlikely to be a satisfactory solution.
Perhaps you would be better served by writing data to the drives in an encrypted form. Thus, after a future failure, under warranty or not, you could be confident that data recovery would be unlikely.
It's been running my raid for a couple of years...I think. I cannot honestly remember when I first configured it.
There are some things to be aware of. If you want to mount / as a raid, it can be tricky. The initrd needs to be properly configured, or the drivers must be built into the kernel.
Sometimes, the raids don't shut-down completely. I've never been able to completely solve this problem. Most of the time it's OK, but some machines have trouble. The most common culprit has been NFS.
GRUB & LILO need some special care when you plan to mount root from a raid mirror. It does work and it has all of the appropriate relibility features.
...on a can of soda pop.
There are situations where median is the most appropriate measure of average. Take the Bush tax-cut for rich Americans. He stated that on average, Americans would receive a several thousand dollar break in their taxes. His number is correct when calculated as a mean. Using similar logic, you would say that when Bill Gates walks into a bar, the average income of the patrons rises by millions of dollars--I hope you agree that this is a pointless use of the mean. On the other hand, if Bush has been more honest and said that the tax break for the median American was closer to zero dollars, he'd have been much more true to the effect of his program. His tax-cut overwhelmingly affected the highest income earners which is attested by the fact that there is a new tax refund form for refunds over one million dollars.
"You look at this blob on the ground and say, 'There goes our ancestor,' " he said. -- writes Penelope Debelle.
She ought to read Stephen Jay Gould's work before writing about science. Her statement, in fact, is very much wrong. The common supposition that there is a steady march from simple forms to more complex ones is well debunked by Gould. There is plenty of evidence that the same morphology has been developed by several species. Some survive. Others are pruned. Likewise, there is no reason to believe that this creature is an ancestor of modern chordates.
Their system is based on someone else's work. I forget who. It's called a CardEngine. The CPU card is bit larger than a credit card. There's ethernet, CF slot, audio, and it supports TFT. The board is about $250.
A large percentage of the problems were incomprehensible to me. 'Perhaps,', I thought, 'things have changed a lot since I was an undergraduate.' I showed some examples to a local university professor. He couldn't make sense of the questions either.
I'm told that few graduate CS programs require it.
I work with hardware designed for extreme temperatures. As far as I can tell, these are the prime considerations.
1) Mechanical failure due to thermal expansion and contraction. This tends to affect connectors and plugs. Systems with poorly affixed memory components sometimes experience problems.
2) Dissipation of excess heat. A modest external temperature of 35C may produce a temperature in your trunk of over 45C. At 45C, the CPU will have a hard time dissipating heat since heat diffusion requires a gradient. CPUs may tend to fail around 55C.
3) Condensation. As you open and close the trunk in cooler weather, you'll be adding moisture to the closed space. Like dew, moisture will condense out of the air as components cool. Moisture on electronics tends to be less than optimal.
4) Vibration. Automobiles are notoriously hard on electrical components because of the constant vibration. Single strand wire tends to fatigue. Connectors shake loose. There are mounting methods for abating shock and vibration.
The systems we use for extreme temperatures do not sport contemporary CPUs because of the heat problems. To cope with condensation, we place desiccants inside the enclosures.
OK. I'll be more specific. Note that this comes from Alteon who helped me diagnose the 'feature' and make the system work. You have a router on port 1 and a host on port 3 that is being load-balanced. There is a VIP that balances load to your host. It accepts requests through the router on port 1. If the switch is *not* a router, then the default gateway to the host has to be another routing device, in this case, the router on port one. A request on the VIP enters through the router, hits the switch, and is selected for processing by the host. The switch sends the packet to the router via layer 2 which means that the arp cache on the switch will bind the MAC address of the router to the IP address of our destination host. The router wants to send the packet the the host, so it sends it back to the switch. The switch attempts to send it back to the router and voila, the packet is dropped. The problem is with the interaction between the layer 2 switching and the layer 3 (which some people call layer 4) routing. By making the switch understand the local route and therefore capable of being the gateway, the arp cache properly points to the port with the host on it. Please keep in mind that I didn't have any specific gripes with Alteon until I came to configure our production network with all of the hosts running. This routing problem wasn't really serious except that is was a hidden consequence of the Alteon design. We did make it a router, but that meant we had to keep it up to date. I preferred to put the routing in a real router since that's what they're designed to do. Routing on the Alteon is second-class to the rest of the features.
Before anything else, I laud the Slashdot team for quickly resolving their network access problems. I've been through something similar and can appreciate the complexity of diagnosing these problems.
..
I spent a statistically average stint deploying servers at exodus for an ecommerce site. I had a couple of odd experiences that I could not completely explain.
First, I, too, received 10/24 packets from the Exodus network that Exodus denied could be coming through their routers. I was using a simple 2600 series router with ACLs to do my filtering/firewalling, so it was quite clear where the packets came from.
I worked with three different load-balancing devices including the F5 and the Alteon Networks devices. None of them met my evaluation criteria of sufficient features and believable reliability. I bought the Alteon device because I could make it work within four hours and it appeared to have the right features. Then, the trouble ensued. The device failed us, under a very meager load, not because it wasn't fast enough, but because the features of the device interact in very complex ways. The fundamental problem is that the mixture of a switch, router and load-balancer in once device doesn't agree with IP. ITOT, we had to use it for all three even though we had a router that we preferred to use as...a router, dummy.
Lastly, we used a Debian GNU/Linux box as a gateway through the firewall using the cipe VPN code. This was the most reliable piece. Although, to be fair, it wasn't maintenance free. There were times with the VPN link would drop without explanation. Fortunately, we never lost contact with the box and so we could always nudge the link.