fuhrman@b.coe.wvu.wvnet.edu (Cris Fuhrman) (08/11/89)
Can anyone tell me what the length for an 8mm tape drive is while using dump in SUN OS 3.5? -Cris Fuhrman
chris@mimsy.UUCP (Chris Torek) (08/11/89)
In article <412@h.cs.wvu.wvnet.edu> fuhrman@b.coe.wvu.wvnet.edu (Cris Fuhrman) writes: >Can anyone tell me what the length for an 8mm tape drive is >while using dump in SUN OS 3.5? No. (That is, no one can tell you.) The length you give to dump is plugged into a formula designed for 9-track tape reels at 800, 1600, and 6250 BPI, and not for any of the cartridge formats. Moreover, all existing 8 millimeter tapes (which all use Sony transports, Sony cartridges, and Exabyte's data format, with the drive electronics being from Exabyte, so as it happens it does not matter which manufacturer's 8mm tape drive and cartridge is being used; but this is an unusual and probably temporary situation) are capable of writing either `long tape marks' or `short tape marks', and the amount of data that will fit onto a single cartridge depends to a great extent on how many long tape marks are written. This in turn depends on whether your software and hardware uses long or short tape marks, and on how many files you put on a cartridge. In general, however, the average installation has less disk data to back up than fits on a single one of these cartridges, so any length close to infinity suffices. We have been using the command dump 0ufds /dev/tape/1n 6250 32000 <filesystem> but the 32000 here is just a WAG, and depends on this `infinite length' property. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
starr@mrsvr.UUCP (Larry Starr,Mezzanine,46971,5638828) (08/11/89)
From article <412@h.cs.wvu.wvnet.edu>, by fuhrman@b.coe.wvu.wvnet.edu (Cris Fuhrman): > Can anyone tell me what the length for an 8mm tape drive is > while using dump in SUN OS 3.5? I believe that what you are after is not the physical length of the tape but a logical length. What we are using for dump, with an 8mm Exabyte (2.2G tape) is: dump ds 6250 28633 Add other flags as necessary and, of course, specify your file system, tape drive, etc. This allows dump to calculate a capacity of 2G bytes for the tape, I rounded down to play it safe. Your mileage may vary.
laplant@engr.wisc.edu (dave laplant) (08/11/89)
In article <18999@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > In article <412@h.cs.wvu.wvnet.edu> fuhrman@b.coe.wvu.wvnet.edu > (Cris Fuhrman) writes: > >Can anyone tell me what the length for an 8mm tape drive is > >while using dump in SUN OS 3.5? > > No. > yes. according to the documentation i receive with our 8 mm tape drive, the tape is 346 feet long and has density of 4.4 megabits per inch. HOWEVER, the density is higher than dump can handle, and they recommend using a size of 6000 and a density of 54,000. this will specify the correct size. -dave laplant (laplant@engr.wisc.edu)
chris@mimsy.UUCP (Chris Torek) (08/11/89)
>>>Can anyone tell me what the length for an 8mm tape drive is >In article <18999@mimsy.UUCP> I answered: >>No. In article <111@engr.wisc.edu> laplant@engr.wisc.edu (dave laplant) writes: >yes. > >according to the documentation i receive with our 8 mm tape drive, the tape >is 346 feet long and has density of 4.4 megabits per inch. HOWEVER, the >density is higher than dump can handle, and they recommend using a size >of 6000 and a density of 54,000. this will specify the correct size. Nope. (Pretty close, though....) Here are the magic calculations from the 4.3BSD dump (which is what we use everywhere---if you are using the SunOS dump under SunOS, you should switch to the 4.3BSD dump): if 'c' flag: float fetapes = ( esize /* blocks */ * TP_BSIZE /* bytes/block */ * (1.0/density) /* 0.1" / byte */ + esize /* blocks */ * (1.0/ntrec) /* streaming-stops per block */ * 15.48 /* 0.1" / streaming-stop */ ) * (1.0 / tsize ); /* tape / 0.1" */ where esize is the number of 1024-byte blocks dump thinks it is to dump; density is the value from the `d' flag, divided by 10; ntrec is 10, or the value from the `b' flag, or if `d' given but `b' not, and density >= 625 (i.e., `dump d 6250' or more), 32; and tsize is the tape size from `s', in units of 0.1 inch, default 2300*120 if not cflag, or 1700*120 if cflag. (I will get to the `regular' method, i.e., non-cartridge, in a moment. Just trying to be thorough.) So if you used `0ufdsc' with d=54000 and s=6000, we have: ( esize * 1024 * (1.0/5400) + esize * (1.0/32) * 15.48 ) * (1.0 / (6000*120)); We want this to come out to 1.0 for esize being approximately 2 GB (in units of 1024 bytes), so plug in esize=(2*1024*1024): bc << end scale=10 (2*1024*1024 * 1024 * (1.0/5400) + 2*1024*1024 * (1.0/32) * 15.48) \ * (1.0 / (6000*120)) end 1.9612345480 tapes. But then, we were not using the `c' flag anyway. On to the other calculation. All variables are as before: if not cflag: int tenthsperirg = (density == 625) ? 3 : 7; float fetapes = ( esize /* blocks */ * TP_BSIZE /* bytes / block */ * (1.0/density) /* 0.1" / byte */ + esize /* blocks */ * (1.0/ntrec) /* IRG's / block */ * tenthsperirg /* 0.1" / IRG */ ) * (1.0 / tsize ); /* tape / 0.1" */ so we have ( esize * 1024 * (1.0/5400) + esize * (1.0/32) * 7 ) * (1.0 / (6000*120)) and again we will use 2 meg for esize (which is in terms of 1024 bytes): bc << end scale=10 (2*1024*1024 * 1024 * (1.0/5400) + 2*1024*1024 * (1.0/32) * 7) \ * (1.0 / (6000*120)) end 1.1894155032. Oops. Not bad, though; a bit on the conservative side, but that is generally best. But---as I pointed out in my original posting---none of this matters anyway! The important question that has to be answered before you can give a size for these tapes is: How many long tape marks will you write? With a tape capacity of 2.2+ GB, and disks of 100 to 600 MB being common, obviously you will want to put many dumps on each tape. EVERY DUMP IS SEPARATED BY A TAPE MARK, and each long tape mark consumes approximately 2 MB worth of tape! (This is only 1/1024 of the tape, but if each dump is ~100 MB, it is still a running 2% error.) If you use short tape marks, this question goes away, but then the tapes get very hard to reposition. Oh, just for fun, let me see how close my d=6250,s=32000 `WAG' came: bc << end scale=10 (2*1024*1024 * 1024 * (1.0/625) + 2*1024*1024 * (1.0/32) * 3) \ * (1.0 / (32000*120)) end Only .9459243103. Maybe not conservative enough. To check, plug in 2.28 GB: bc << end scale=10 (2.28*1024*1024 * 1024 * (1.0/625) + 2*1024*1024 * (1.0/32) * 3) \ * (1.0 / (32000*120)) end 1.0711861724. Whew! ( :-) ) (I got the 32000, of course, by solving for esize at density=625, ntrec=32, back when we installed the drives.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
merlyn@iwarp.intel.com (Randal Schwartz) (08/16/89)
In article <18999@mimsy.UUCP>, chris@mimsy (Chris Torek) writes: | In general, however, the average installation has less disk data | to back up than fits on a single one of these cartridges, so any | length close to infinity suffices. We have been using the command | | dump 0ufds /dev/tape/1n 6250 32000 <filesystem> | | but the 32000 here is just a WAG, and depends on this `infinite | length' property. Our vendor told us to use 43000 for a density and 120000 for a length (for a 2-hour tape). That works out to about 1.3 GBytes (roughly infinity, yep :-). Just another system hacker, -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel, Hillsboro, Oregon, USA | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/