jv@mh.nl (Johan Vromans) (07/25/90)
I have noticed that dump(8) does not utilize TK50 tapes as it should.
A TK50 can hold about 90Mb of (formatted) data. To dump 200Mb of disk,
dump(8) uses 3.24 tapes. This reates about 60Mb per tape.
When I supply dump with a huge tape length argument, say 13200, it
needs only about 2.5 tapes to dump the same amount of data. However,
dump(8) calculates that it needs 0.3 tapes...
What are the optimal parameters for a TK50? From the specifications,
A TK50 has 600 ft, 6667 BPI, 22 tracks. This yields either density =
22*6667 and length = 600 ft, or density = 6667 and length = 22*600 ft.
Johan
--
Johan Vromans jv@mh.nl via internet backbones
Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62911/62500
------------------------ "Arms are made for hugging" -------------------------kbesrl@ux1.cso.uiuc.edu (07/26/90)
I noticed similar problems with both TK50 and TK70. I would also like to know what density and length options to use. Thanks. -- sudhakar
grr@cbmvax.commodore.com (George Robbins) (07/26/90)
In article <1990Jul25.110248.14366@squirrel.mh.nl> Johan Vromans <jv@mh.nl> writes: > I have noticed that dump(8) does not utilize TK50 tapes as it should. > > A TK50 can hold about 90Mb of (formatted) data. To dump 200Mb of disk, > dump(8) uses 3.24 tapes. This reates about 60Mb per tape. > When I supply dump with a huge tape length argument, say 13200, it > needs only about 2.5 tapes to dump the same amount of data. However, > dump(8) calculates that it needs 0.3 tapes... Because of the streaming technique used on the TK50, the exact capacity varies according to the system performance. Any time the system isn't ready, the TK50 wastes a little bit of tape. If it still isn't ready, it will backspace, stop and wait, so the tape isn't wasted, but it runs real slow. If you accept the default Ultrix tape sizes then it will use a "safe" figure that will "never" hit the end of the tape. However, since Ultrix 3.x there is automatic end-of-tape sensing that you can use instead of letting dump play it safe. What I do is specify 10 times the nominal length to force dump to rely on end-of-tape sensing, but still be able to make some sense out of the estimated number of tapes needed. -- 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)