On Tue, Sep 06, 2005 at 02:50:40PM -0700, DJA wrote: > Lan Barnes wrote: > >Over the weekend I installed a 6 G Quantum IDE HD as added space on my > >SCSI server. I had no problem. I then moved about 2 G of digital photos > >to it and deleted them from the original space. A mistake. > > Was this a known good hard drive? >
Good on last machine is all I can attest to. > > > >Several of these steps are now obvious mistakes. > > As in the difference in safety between cp+rm vs. mv? ;-) > Hmm ... that part worked OK. It was the cp across NFS on the wireless that got me. > > >The server now refuses to come up with this HD on line. It gives a > >message that there is a I/O buffer failure on /dev/hdd (the "new" drive) > >while loading init, and refuses to boot past that, even when the drive > >is removed from /etc/fstab and the BIOS. I have to take power off the > >drive to boot up. Then everything is OK, except my photos are gone. > > Are you sure the server's power supply is up to the added loaded of an > additional HD? > No, I'm not. And I actually thought about it. But it wasn't meaningful thought, because I'm pretty ignorant in those areas. But I did have to add a pigtail splitter (first one on this box). And the drive worked on the box for a couple of days before the sad event. - 2 scsi HDs - 1 CD ROM - 1 CD/DVD R/W - 1 floppy - and the new IDE HD > > >So what is recommended? I plan to try (in this order) > >Remarks or advice? > > I suggest that you download and run the drive mfgr's diagnostic software > before you go mucking with the drive yourself. Generally that > software boots from floppy or CD so you can disconnect power from any > other drives first, in case it really is a PS problem. > Good idea! I'll do it! > > As I always recommend: do *not* jump to the conclusion that your HD is > bad just because data is being corrupted or even if it doesn't work. > It's not running in a vacuum. It depends on several other critical > components in your system to do its job reliably. > Your recommendations are one of the reasons I post here. > Another lesson that might or not be relevant here: don't put critical > data on a questionable and untested lump of hardware. > Well, that and archive valuable data before screwing around with it. -- Lan Barnes [EMAIL PROTECTED] Linux Guy, SCM Specialist 858-354-0616 -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
