Sam Clemens wrote:
Use tar to make a (logical) image of the filesystem onto another disk, then use mkfs.reiserfs to re-format the partition, and then restore your tar image back to the original disk.
Sam Clemens wrote:
So you want to tempt fate and be back in this same position next week?
Get the data off the drive, put it on new hardware, and get rid of the failing drive.
Unless you really have a secret desire to lose all your data.
Sam Clemens wrote:
If he's been having trouble reading from it, and it can't be attributed to the controller or the cable, then the disk is, by definition, unreliable.
Sam, I know you're trying to be helpful but I believe my problem is fixed and I think you misunderstand the problem that I had. I agree with the logic in your last comment but the fact is that I did *not* have any trouble reading data. There's been no indication of any hardware problems in drives, cables, controller, motherboard, processor or anything else. The trouble I had was an inability to *write* data and that has been identified as a kernel bug and fixed by updating the kernel. My problem is solved, so let's bring the thread to a close. Please reread my postings if you still have questions about the fault. FWIW, I have previously had two drives fail in this array. The 3ware hardware has coped as it is designed to. It notifies me of a failing drive; I pull the drive and replace it with a new one (which I can get from the stock we keep) and tell the controller to rebuild the array. In case that doesn't work, there's a nightly backup :) And yes, Carlos, smart is running on the drives, monitored by the controller :) Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org