I have a large number of desktop Unix boxes running NCR's SVR4.  They all
have the same type of SCSI hard disk.  Due to their advanced age, a unit's
disk will die every now and then.  I get the failed unit going again by
replacing the failed disk, then using dd on a working system to copy its
internal disk to an external disk, then move the external disk to the
failed system and dd the external disk to the new internal disk.  Of
course, I have to fsck the new internal disk and change a few files, but
this procedure works.

I'm considering considering writing a Linux client-server application using
UDP to do a disk-to-disk copy over an Ethernet network.  Here's how I
envision it working:

Shut down a working system and boot it with Linux boot diskette; this will
be the server.

Boot failed system with Linux boot diskette; this will be the client.  Note
that I've replaced the hard disk prior to this step.

Start server and client programs.  The data transfer is something like this:

        Server:  read N 1KB disks blocks (N is probably in [4..30]);
                compute CRC;
                write buffer (CRC plus disk blocks) via UDP;
                wait for ack/nack.
        Client: read UDP packet from server;
                verify CRC, send nack if CRC is incorrect;
                write N 1KB disks blocks;
                send ack to server;
        Server: if ack, go to top of loop;
                if nack, retransmit buffer;
                wait for ack/nack.

Of course, there's lots of little details I left out (UDP packets getting
lost, end-of-file action, screen updates on client and server to track
progress, etc., etc., etc.).  I still have to fsck the failed system and
change a few files, but this would be *much* quicker than the
process I have now!

I'd never consider doing this on an O.S. other than Linux!

Has anybody out there done anything like this?

Thanks for your feedback.

Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]

Reply via email to