Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Data\s+on\s+my\s+tapes\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Data\s+on\s+my\s+tapes\s*$/: 8 ]

Total 8 documents matching your query.

1. Data on my tapes (score: 1): Author: David DeCuir <David.Decuir AT CLUBCORP DOT COM>; Date: Wed, 20 Jun 2001 09:58:06 -0500; Hello, Ok, how much data are you getting on a 3590 "K" tape. From reading past posts, I know the Pct Util and Est. Capacity method is suspect at best. All I need is an average you guys have seen usin; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-06/msg00688.html (11,572 bytes)
2. Re: Data on my tapes (score: 1): Author: Richard Sims <rbs AT BU DOT EDU>; Date: Wed, 20 Jun 2001 11:27:33 -0400; David - A rough visual average that I see on my full tapes is 58 GB, in backup and copy storage pools. (If using HSM, expect much less, because it doesn't Aggregate.) Richard Sims, BU; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-06/msg00695.html (10,698 bytes)
3. Re: Data on my tapes (score: 1): Author: Jim Taylor <jtaylor AT ENLOGIX DOT COM>; Date: Wed, 20 Jun 2001 08:39:09 -0700; David, for what it is worth, Here is a excerpt from a 'q vol' of some tapes marked as full from my system. -- -- -- Volume Name Storage Device Estimated Pct Volume Volume Name Storage Device Estimate; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-06/msg00698.html (11,932 bytes)
4. Re: Data on my tapes (score: 1): Author: Jeff Bach <jdbach AT WAL-MART DOT COM>; Date: Wed, 20 Jun 2001 11:11:15 -0500; What is my problem? I am just going to 3590K. I use client compression on everything. I compress on the tape drives also. I tried to define the format as 3590b, but it doesn't allow me to access the; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-06/msg00703.html (12,850 bytes)
5. Re: Data on my tapes (score: 1): Author: "Thomas A. La Porte" <tlaporte AT ANIM.DREAMWORKS DOT COM>; Date: Wed, 20 Jun 2001 09:37:46 -0700; Jeff, Compressing more than once generally doesn't gain anything in terms of space reduction, in fact there are certain instances in which additional compression passes result in *larger* files. Sinc; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-06/msg00705.html (14,133 bytes)
6. Re: Data on my tapes (score: 1): Author: Robin Sharpe <Robin_Sharpe AT BERLEX DOT COM>; Date: Wed, 20 Jun 2001 16:15:01 -0400; FYI, here are my results (using DLT7000 drives) on my three largest storage pools... NT_TAPE is (obviously?) all NT servers, GEN_TAPE is Unix servers, and COLOC_TAPE is collocated Unix servers. I fou; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-06/msg00715.html (13,527 bytes)
7. Re: Data on my tapes (score: 1): Author: Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU>; Date: Fri, 22 Jun 2001 09:48:57 -0400; Quoting David DeCuir <David.Decuir AT CLUBCORP DOT COM>: Oracle .dbf files are initially allocated at a pre-specified size and populated with long runs of zero bytes. Some of the zero bytes are repla; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-06/msg00796.html (11,613 bytes)
8. Re: Data on my tapes (score: 1): Author: Mark Stapleton <stapleto AT BERBEE DOT COM>; Date: Thu, 28 Jun 2001 23:05:16 -0500; Not exactly on topic here, but you actually lose throughput when you run compression on both ends of the process. You're better off with tape compression only; the hardware compression algorithm is f; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-06/msg01057.html (11,173 bytes)

Current List: 1 - 8
Page: [1]