Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!nrl-cmf!cmcl2!brl-adm!adm!Postmaster%TRINCC.BITNET@mitvma.mit.edu From: Postmaster%TRINCC.BITNET@mitvma.mit.edu (PMDF Mail Server) Newsgroups: comp.unix.questions Subject: Undeliverable mail Message-ID: <16413@brl-adm.ARPA> Date: 7 Jul 88 04:57:29 GMT Sender: news@brl-adm.ARPA Lines: 56 The message could not be delivered to: Addressee: TRIN4 Reason: %MAIL-E-SYNTAX, error parsing 'DJA1::[TRIN4.BOX1024]' ---------------------------------------- Received: from JNET-DAEMON by TRINCC.BITNET; Fri, 1 Jul 88 13:52 EST Received: From YALEVM(MAILER) by TRINCC with Jnet id 7349 for TRIN4@TRINCC; Fri, 1 Jul 88 13:52 EST Received: by YALEVM (Mailer X1.24) id 7345; Fri, 01 Jul 88 01:41:13 EST Date: Thu, 23 Jun 88 07:25:02 MST From: Duke MangumSubject: labelit/volcopy. Sender: Info-Unix distribution list To: Robert Cummings Reply-to: INFO-UNIX@BRL.ARPA Comments: To: info-unix@BRL.ARPA Hope someone out there has an answer to this problem : I'm the SA on a Unisys ( Sperry ) 5000/80. A week or so ago, I was getting ready to do some file system volcopies. The target device for the volcopies is a 1600 bpi Cypher tape drive. The first file system I went to volcopy required three reels, so I executed 'labelit' on these three reels preparatory to using them. I used labelit as follows ( the reel/volume names changed for each reel, of course ) : labelit /dev/rmt/c0d0h work 1462 -n I next used labelit to verify the labels on the three tapes. So far, so good ! I then did the volcopy - no problems. The next file system I needed to volcopy required two reels. I used labelit ( -n ) as above to label these tapes; however (comma) when I then used labelit to verify the labels, I got a 'printout' of the labels followed by the nastygram : "illegal blocksize=512" Subsequent attempts to get around this, using different variations of everything I could think of, produced no change. Finally, I decided to go ahead and try the volcopy. The file system I was volcopying has a partition size of 50024 blocks. At the end of the volcopy execution, the blocks copied figure was 100048 blocks. 'Restoring' from these tapes produces the same block count, however a subsequent 'df -t' shows the partition to be the expected size. What is irritating is that, if memory serves me correctly, I had this same problem on our Gould 6032 about two years ago, but I do NOT remember what caused it and how I finally got around it; I just remember that I did. I called this situation in on the Unisys 'hotline', but they seem to feel ( at the moment, anyway ) that this is not a problem ! If anyone out there has a solution to this problem, I would *really* appreciate it. If I didn't have a memory fault in this sector, it wouldn't BE a problem. Many (hopeful) thanks in advance.