adeboer@gjetor.geac.COM (Anthony DeBoer) (02/13/91)
I periodically get tapes from client's systems or other sources where the precise tape format isn't documented. What I'm looking to find out is if there's a way to determine exactly what block size was used when the tape was written, or even if this is a major requirement (should I even be worrying about it or not?). Reading with a tasteful default value usually seems to work (even a 512-byte block size has worked before, although at tremendous loss of efficiency), but I'm wondering if there's any chance of data loss with the wrong block size, or any rule of thumb for optimizing things. I have several systems here, so as far as naming my hardware/software configuration goes I'll just mention the Unisys 6000/50 running SVR3.0 with a 150meg QIC drive. And I shouldn't forget the old Convergent Technologies Mightyframe. -- Anthony DeBoer NAUI#Z8800 | adeboer@gjetor.geac.com | Programmer (n): One who Geac J&E Systems Ltd. | uunet!geac!gjetor!adeboer | makes the lies the Toronto, Ontario, Canada | #include <disclaimer.h> | salesman told come true.
grr@cbmvax.commodore.com (George Robbins) (02/16/91)
In article <1991Feb12.224353.6514@gjetor.geac.COM> adeboer@gjetor.geac.COM (Anthony DeBoer) writes: > I periodically get tapes from client's systems or other sources where the > precise tape format isn't documented. What I'm looking to find out is if > there's a way to determine exactly what block size was used when the tape was > written, or even if this is a major requirement (should I even be worrying > about it or not?). Reading with a tasteful default value usually seems to > work (even a 512-byte block size has worked before, although at tremendous > loss of efficiency), but I'm wondering if there's any chance of data loss with > the wrong block size, or any rule of thumb for optimizing things. dd if=/dev/nrmt* of=diskfile bs=65535 count=1 ; ls -l diskfile ... - or - dd if=/dev/nrmt* bs=65535 count=1 | wc -c Different tape devices have different characteristics. A sun type cartridge tape is insensitive to blocksize (except as a performance issue), traditional raw 9-track tapes may well lose data... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
gwyn@smoke.brl.mil (Doug Gwyn) (02/16/91)
In article <1991Feb12.224353.6514@gjetor.geac.COM> adeboer@gjetor.geac.COM (Anthony DeBoer) writes: >... if there's a way to determine exactly what block size was used when the >tape was written, or even if this is a major requirement (should I even be >worrying about it or not?). Assuming your tape subsystem conforms to long-established UNIX practice, if the read() system call specifies a read count less than the actual block size when reading the "raw tape" device (which is the usual one), you should get an I/O error since data will be lost. (If you're trying to read a "tar" or "cpio" archive, and data ever does get silently lost, you should see archive checksum comparison errors.) For read counts in excess of the block size, read() returns the actual amount of data read, not the requested size. Therefore the usual practice is to try to read using an over-generous allocation for the input buffer, which should not introduce any significant amount of inefficiency. If you have an oddball device driver or hardware, you may be out of luck.
rbj@uunet.UU.NET (Root Boy Jim) (02/28/91)
In article <15222@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Assuming your tape subsystem conforms to long-established UNIX practice, >if the read() system call specifies a read count less than the actual >block size when reading the "raw tape" device (which is the usual one), >you should get an I/O error since data will be lost. I agree with everything Doug said. However, I would like to add that while mtio(4) says that an error will be returned, many device drivers will not return one. The only source (Tahoe) I have available to look at (Lions is at home) says things like: /* * If we were reading raw tape and the only error was that the * record was too long, then we don't consider this an error. */ -- [rbj@uunet 1] stty sane unknown mode: sane