Thanks to the following sunmanagers for their help: adh@an.bradford.ma.us (Sandwich Maker) andrew.crichton@accenture.com Bill R. Williams" <brw@etsu.edu Bill Williams had the solution which required adding the "b" option for blocking factor 512. I tried using the following command and it completed a full dump of 41.48GB without hitting the end of tape! Thank you Bill. Bill had quite a detailed summary which I will place here because it contains such useful information. Carolyn Mayr =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Carolyn Mayr (IT Specialist/ITSD Support) Voice: 410-293-6808 (sec-6800) Computer Science Department, DivMath&Sci Email: carolyn@cs.usna.edu 572M Holloway Road, Michelson Hall, 9F FAX: 410-293-2686 U.S. Naval Academy WWW: http://www.cs.usna.edu Annapolis, MD 21402-5002 USNA: 410-293-1000 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------- Begin Forwarded Message ------------- Date: Mon, 13 Mar 2006 13:40:54 -0500 From: "Bill R. Williams" <brw@etsu.edu> To: Carolyn Mayr {ITSD/CS} <carolyn@cs.usna.edu> Subject: Re: DAT 72 tape drive (hits end of tape) -- REVISITING On Mon, Mar 13, 2006 at 11:45:16AM -0500, Carolyn Mayr {ITSD/CS} wrote: > Thank you. I am trying the bigger block size: > > /usr/sbin/ufsdump 0ubf 512 /dev/rmt/1cn /dev/dsk/c1t0d0s0 > > Since I am specifying a block size argument in ufsdump, do I have > to specify it when I do a ufsrestore as in: > > ufsrestore -ifb 512 /dev/rmt/1cn Yes, but remember the the ufs-dump/restore utilities are a bit different the the others in that: 1. Their options (ifb) do not start with the dash(-)! 2. The options are specified all together and then the option values are specified *in the order* of the options! Which means that the correct form is: ufsrestore ibf 512 /dev/rmt/1cn where i: interactive (is that what you really mean?) i takes no value, so there's no matching argument b: means blocking factor will be specified f: means read from the specified file/device and the values for those options requiring a value (b,f) come next IN ORDER: 512 -- for the 'b' /dev/rmt/1cn -- for the 'f' Most commonly you would see either e[x]tract, [r]ecursive restore, or [t]able of contents. You could list the files on your tape with: ufsrestore tbf 512 /dev/rmt/1cn BTW: the reason you have to specify the blocksize on ufsrestore or whatever else you read the tape with is mainly so that the utility can know how much memory to allocate for buffer! Biggie Tip: ALWAYS know the blocking factor of your backup tapes! Once you establish what you want to use as your standard: * Be consistant - stick with the same blocksize for all your tape I/O. Easier to remember! * Indicate in your tape logs, docs, etc. what blocksize is used. * Indicate on the physical tape labels the utility which created the tape and, of course the blocksize. Yes, you can figure out what the blocksize is as we have seen using the 'dd' utility. BUT, if it's a backup tape and your only system which can read the tape is the one being recovered the guessing game can get real tedious really quickly. > I appreciate your help. I will let you know what happens with > the ufsdump results. > Carolyn Mayr You're welcome! -- --------------------------------------------- Bill R. Williams <brw@etsu.edu> ------------------------ ETSU Library Systems > ------------- Begin Forwarded Message ------------- > Date: Mon, 13 Mar 2006 11:23:43 -0500 > From: "Bill R. Williams" <brw@etsu.edu> > To: Carolyn Mayr {ITSD/CS} <carolyn@cs.usna.edu> > Subject: Re: DAT 72 tape drive (hits end of tape) -- REVISITING > > Lemme see what we have here... > > On Mon, Mar 13, 2006 at 09:49:20AM -0500, Carolyn Mayr {ITSD/CS} wrote: > > I ran: > > dd if=/dev/rmt/1mn of=/tmp/tape.block count=1 bs=512k > > > > and the file created is: > > > > -rw-r--r-- 1 root other 32768 Mar 13 09:43 tape.block > > This tells me that you are (by default) writing 32KB tape blocks. > > According to my "man ufsdump", the [b]locksize is specified as the > number of 512-byte blocks -- two of them make 1K. > Looking at the results of your 'dd' above, the default blocksize being > written to your tape is 32768 which is 32KB which is 64*512. So your > original command: > > /usr/sbin/ufsdump 0uf /dev/rmt/1cn /dev/dsk/c1t0d0s0 > is equivalent to: > /usr/sbin/ufsdump 0ubf 64 /dev/rmt/1cn /dev/dsk/c1t0d0s0 > because you are actually (by default) writing 32KB blocks which is 64*512. > > > So should I used this ufsdump line based on the above or should I > > change the 256? I'm not sure how to do the math: > > The above shows what you are currently writing. What you want to do > is write great-big-ol blocks to see if you can fit your data on the > tape. If it were me I would go ahead and try the 128KB blocks > (256*512) as in, YES try this: > > # /usr/sbin/ufsdump 0ubf 256 /dev/rmt/1cn /dev/dsk/c1t0d0s0 > > If you want to experiment you can go ahead and try to write an even > BIGGER block -- say a 256KB which is 512*512 which is like this: > # /usr/sbin/ufsdump 0ubf 512 /dev/rmt/1cn /dev/dsk/c1t0d0s0 > > BTW: If I remember the '1cn' indicates drive=1 compress no-rewind. > (My drive has a different set of device specifiers.) > BE SURE to rewind before you do any of the ufsdump, dd, cpio, etc. > things! :-) > > Anyway, experiment and see how it goes. > * The argument associated with the ufsdump [b]locksize is always twice > the size of the number of KB your want to write. > * The whole point is to write fewer blocks onto the tape; each tape > block has the InterRecordGap which is wasted space. > > After you write your tape, rewind and use the 'dd' to be sure that you > are getting the blocksize you specified. > > --------------------------------------------- > Bill R. Williams <brw@etsu.edu> > ------------------------ ETSU Library Systems > > > > ------------- Begin Forwarded Message ------------- > > Date: Mon, 13 Mar 2006 09:36:44 -0500 > > From: "Bill R. Williams" <brw@etsu.edu> > > To: Carolyn Mayr {ITSD/CS} <carolyn@cs.usna.edu> > > Subject: Re: DAT 72 tape drive (hits end of tape) -- REVISITING > > > > Hi Carolyn, > > > > Something which *may* be useful and is "old school" to the very > > beginning of tape drives in which the tapes were made of stone ... > > > > No, seriously. Here is my personal (opinion) rule for using tape > > devices: > > Always write the biggest block the device will allow! > > Sub-rule: > > Always set your tape device so that the software can control > > the blocksize. (Usually indicated by the device having BLKSIZE 0.) > > > > It makes a tremendous difference! The reason is that every block is a > > "physical" entity on the tape, and the default blocking factor for > > 'ufsdump'is 10K. There is an Inter Record Gap (IRG) which consumes > > some physical tape length between the blocks; therefore, the more > > blocks you write the more IRGs you have and the more linear tape you > > use. Or to put it simply: > > 100 blocks at 100K takes up much less tape than 1000 blocks of > > 10K. MUCH LESS. > > > > I get the impression that most newer tape devices can handle blocks of > > at least 64K, probably 128K, possibly 256K, maybe even more. Any of > > those is preferred over the default 10K. > > If we pretend that your tape drive will handle 64K blocks I would > > suggest you use this: > > /usr/sbin/ufsdump 0ubf 128 /dev/rmt/1cn /dev/dsk/c1t0d0s0 > > where the [b]locking factor of 128 (* 512) == 64K. > > Actually, I recommend that you go ahead and try for 128K blocks: > > /usr/sbin/ufsdump 0ubf 256 /dev/rmt/1cn /dev/dsk/c1t0d0s0 > > I expect that your tape drive will let you know immediatly if it can't > > handle that size block. If it can: WHoopeeee! > > > > IMPORTANT Safety Tip: > > Be SURE that you lable and/or log the blocksize used to write > > your tapes! You will need to specify it when reading the tape > > so the utility will know how big a buffer to allocate for a > > tape read. > > > > HINT: > > You can find out the blocksize of a tape by copying the first > > block to a disk and looking at its size. Like this: > > dd if=YOURTAPEDEVICE of=/tmp/tape.block count=1 bs=512k > > dd if=/dev/rmt/1cn of=/tmp/tape.block count=1 bs=512k > > > > The 'bs=' is specified so that 'dd' will know how much buffer > > to allocate , and the 'bs=512' presumes that the block will > > not be bigger than 512K -- if you discover that your tape will > > write a bigger block, then just use that. > > > > Anyway, after the 'dd' the /tmp/tape.block will be the size of > > the (current) physical tape block. > > > > I suspect that using a big blocksize will solve your problem. > > (I'd be interested to know if it does.) > > > > Of course there is a finite limit. No matter how big the blocksize or > > how much the tape drive compresses, you can only get so much data on > > there. :-) > > --------------------------------------------- > > Bill R. Williams <brw@etsu.edu> > > ------------------------ ETSU Library Systems > > ORIGINAL MESSAGE: > > On Mon, Mar 13, 2006 at 07:12:49AM -0500, Carolyn Mayr {ITSD/CS} wrote: > > > Hello everyone, > > > > > > I have a SunFire V480 (Solaris 9) with a Sun StorEdge DAT 72 tape drive. > > > I am using DAT-72 (36GB/72GB) tapes. > > > > > > My dump parameters are "1cn" based on a previous sunmanagers > > > inquiry. Here's my dump parameters: > > > > > > /usr/sbin/ufsdump 0uf /dev/rmt/1cn /dev/dsk/c1t0d0s0 > > > > > > But now it is hitting the end of tape around 41GB. Is there anything > > > I can do to compress it to fit more data on the tape? I've been > > > searching archives and man pages and can't find anything. Thank you > > > and I will summarize. _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Mon Mar 13 17:25:15 2006
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:56 EST