sys-jdf@cs.rit.edu (John D Fulreader) (11/02/90)
Problem with afio I am having problems using afio when archiving data across a network. I am attempting to write from an AT&T 3B2 600 running System V 3.2.1 onto a reel to reel tape device physically mounted on a Sun 3/280 running SunOS 4.0.3. TCP/IP is used across an Ethernet network. When attempting to read an archive, spurious "BAD MAGIC NUMBER" errors occur. The archive can be read on the local Sun so the archive file is not corrupt. The problem arises when the 3B2 reads the archive off the pipe. In attempting to solve this problem I have observed: - there is no relationship between the type of file (binary,text,etc) and the corruption of that file - varying the archive block size does not seem to improve the problem (tar uses large block size to allow it to work across a communications channel that may not maintain block size) - the problem improves when the -c buffer count option is used(afio recommends a large count when using a streaming magnetic tape drive) - improvement when a wait loop is used in the remote process that sends archive data through the pipe to the local afio process - the problem is worse with greater load on the network I would appreciate any suggestions or information concerning this problem.
les@chinet.chi.il.us (Leslie Mikesell) (11/04/90)
In article <1961@cs.rit.edu> sys-jdf@cs.rit.edu (John D Fulreader) writes: > I am having problems using afio when archiving data across a network. > I am attempting to write from an AT&T 3B2 600 running System V 3.2.1 onto a > reel to reel tape device physically mounted on a Sun 3/280 running SunOS > 4.0.3. > TCP/IP is used across an Ethernet network. When attempting to read an archive, > spurious "BAD MAGIC NUMBER" errors occur. The archive can be read on the local > Sun so the archive file is not corrupt. The problem arises when the 3B2 reads > the archive off the pipe. The BAD MAGIC NUMBER would only occur when the cpio header for an archived file appears not to be correct. Chances are that other errors are also occuring in the data stream. Afio simply generates an "rsh" command to build a pipe to another copy of afio running on the remote system handling the device. Chances are that your rsh is broken. You might test it with some other commands that move a large amount of data. Otherwise the blocking info is not being passed correctly to the remote command. You should be able to check how the command was passed with a ps -ef on the remote machine while it is running. Les Mikesell les@chinet.chi.il.us