volvopilot
asked on
cpio: read error: Cannot allocate memory
I'm trying to use a SCSI tape to restore information taken from machine A, onto machine B. Machine A and B are somewhat dissimilar physically, but both have Linux 7.2 Red Hat installed. They're both Dell Intel PCs. When I used the command on machine C, which is physically identical to machine A, that same restore command worked. On machine B, it fails. Machine C has since been used elsewhere so I can't play with it to verify this for the particular tape in question, but that's how I recall the situation, anyway, from a few months ago.
The syntax I use is:
/cpio -iuvdmBc --no-absolute-filenames -I /dev/st0
It fails almost immediately with:
/cpio: read error: Cannot allocate memory
I have played with the block size parameter. My efforts included omitting it, replacing it with C and feeding various values as a block size, including very small values (1, 4, 16 and so on).
I'm not a Linux guru but an NT / Windows systems administrator. I'm trying to not so much just fix the problem, though that would be nice -- I'd like to understand why this comand is failing, in terms of fundamental reasons. If anyone can translate the problem and its cause to a NT / Windows or MS-DOS concept, that would help me a lot.
When I use the mt command, I can talk to the tape drive, e.g. make it roll forward, so I don't think it's a basic problem in talking to the tape drive.
This is a fresh installation of Linux Red Hat 7.2.
The cpio command was used to make the backup. I don't have the exact syntax but I can get it. Does the syntax / option set of the cpio command, as used to write informaton to the tape, imply that only a specifically matched syntax can be used to restore that tape?
I have looked at the online manual for cpio, and the O'Reilly UNIX in a Nutsgell, and UNIX for DOS users, and I don't see any clue to the cause of the problem.
The syntax I use is:
/cpio -iuvdmBc --no-absolute-filenames -I /dev/st0
It fails almost immediately with:
/cpio: read error: Cannot allocate memory
I have played with the block size parameter. My efforts included omitting it, replacing it with C and feeding various values as a block size, including very small values (1, 4, 16 and so on).
I'm not a Linux guru but an NT / Windows systems administrator. I'm trying to not so much just fix the problem, though that would be nice -- I'd like to understand why this comand is failing, in terms of fundamental reasons. If anyone can translate the problem and its cause to a NT / Windows or MS-DOS concept, that would help me a lot.
When I use the mt command, I can talk to the tape drive, e.g. make it roll forward, so I don't think it's a basic problem in talking to the tape drive.
This is a fresh installation of Linux Red Hat 7.2.
The cpio command was used to make the backup. I don't have the exact syntax but I can get it. Does the syntax / option set of the cpio command, as used to write informaton to the tape, imply that only a specifically matched syntax can be used to restore that tape?
I have looked at the online manual for cpio, and the O'Reilly UNIX in a Nutsgell, and UNIX for DOS users, and I don't see any clue to the cause of the problem.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Okay, I await the results of your tests.
ASKER
I'm about to accept your comment as an answer, not so much because it solved the problem but it was most helpful in figuring out the solution. The cleaning tape may or may not have helped, but after cleaning the drive, the same error message persisted (perhaps now for one reason less, who knows).
I analyzed the backup command used to make the original tape, and I noticed that it sets the block size to 40. So, I removed the B option in the cpio command, and I added the C option, and specified a byte size (per record, I gather) of 20480 (since a block size of 40, times 512 bytes equals 20480). That worked!
So, to re-cap, the revised, working command is:
/cpio -iuvdmc -C 20480 --no-absolute-filenames -I /dev/st0
Thanks again.
I analyzed the backup command used to make the original tape, and I noticed that it sets the block size to 40. So, I removed the B option in the cpio command, and I added the C option, and specified a byte size (per record, I gather) of 20480 (since a block size of 40, times 512 bytes equals 20480). That worked!
So, to re-cap, the revised, working command is:
/cpio -iuvdmc -C 20480 --no-absolute-filenames -I /dev/st0
Thanks again.
ASKER
Please accept my apologies for the delay. I like your incompatibility theory and I plan to test it. Also, I have not run a cleaning cartridge in the drive, and I think that is a good suggestion. I especially like your suggestion of trying to make a tape and then trying to read the data back, on that machine and another machine. I plan to implement your suggestions and get back to you.