Newsgroup: it.comp.retrocomputing
Titolo: 4mm DDS domanda (problemi...)

ho fatto delle prove con il suddetto DAT e ho constatato che backuppando un
archivio già compresso su 4mm dds riescono a contenere un massimo
approssimativo di 1.960.000  (quindi quasi 2 Gb)
ma non dovevano permettere una archiviazione compressa fino a 4 Gb ???
,anche a memoria ricordo chi mi parlava di un valore pari a 4Gb, mentre
quello che ottengo è quasi 2 Gb (sono cartridge 4mm 90M)
ogni spiegazione e consiglio è FORTEMENTE ben accetta !
passo alla seconda domanda, ricordo che su NT esisteva una ulitity per
rilevare la cartridge dds e permetteva di cancellarne il contenuto prima di
lanciare Backup utility, sapete dirmi come cancellare il contenuto sotto
WinXP ? non riesco a trovare suddetta utility che vorrei lanciare prima del
Backup anche perchè spesso il Backup rileva la cartridge come unità già
utilizzata ma non mi chiede di cancellarla fino all'inizio del backup stesso
(vorrei cancellarle prima di ulitizzarle con il Backup utility)
(come prestazioni vi informo invece che trattasi di circa 175 Kb/s quindi
poco più veloce di uno zip parallelo (150 Kb/s)
saluti a it.comp.retrocomputing

poco piů veloce di uno zip parallelo (150 Kb/s)
Questo lo sapevamo gia`, grazie, e dipende dal drive, ma il paragone
proposto non ha senso, per diversi motivi, primo tra tutti il fatto
che uno e` un nastro, l'altro un disco. Non ti rendi conto di cio` che
dici. Anzi, di cio` che pensi.

 poco più veloce di uno zip parallelo (150 Kb/s)
Alla faccia...
I miei DAT HP fanno più di 300 Kb/s!
After-workly,
Seba

 quello che ottengo è quasi 2 Gb (sono cartridge 4mm 90M)
Beh, permettono per l'appunto di memorizzare (al massimo) 4Gb con la
compressione hardware supponendo un rapporto di 2:1. Se gli dai dati già
compressi non riesce a comprimere ulteriormente un bel niente e quindi
il rapporto in scrittura è 1:1 e scrive solamente 2Gb. :) Anzi,
comprimere dati già compressi può portare ad un overhead che aumenta la
dimensione dell'archivio invece che diminuirla.
Ciau,
Angelo

 intelligente capire come ottimizzare tale capienza.
E-person, mi sfugge qualcosa...
9000 cm / 2,54 = 3543,30 pollici
61000 * 3543,30 = 216141732,28 byte (216 Mbyte circa)
Cosa sto sbagliando??? :)))))))
Non è che 61000 va moltiplicato per le tracce?
Se non sbaglio sono 8 per i DAT (?)... 216 * 8 = 1728 Mbyte...
Beh cominciamo ad esserci...
Boh, non mi ricordo, sono troppo pigro e stanco per cercare... :)
Seba

Cosa sto sbagliando??? :)))))))
Che o va moltiplicato per le tracce (ma e` un formato elicoidale) o
non sono 90 metri, bensi` 90 minuti e molti piu` metri. :-)
Devo studiarmelo seriamente.

 Devo studiarmelo seriamente.
Se riesco a rintracciare il manuale del mio DAT, c'č una sezione dedicata al
tipo di registrazione.
Potrebbe essere utile a tutti, in quanto i principi sono poi gli stessi per
tutti i tipi di DAT, siano essi audio o dati o ibridi come quelli per alcune
workstation SGI! :))
Seba

....capisco....grazie.... penso comunque (se ho il permesso di pensare) di
poter dire ciň che penso, senza pensarci su piů di troppo, tu cosa ne pensi
? :)))))
amigaxp


perdere la salute. :(((
Problema noto, l'utility di bakup di w2k e' progettato per gestire le
librerie e aveva un sacco di problemi con i tape singoli (non
avvertiva il cambio del nastro e si rifiutava di scrivere su un nastro
gia' utilizzato anche se usavi /um (cioe' il parametro per gestire le
unita' tape singole)
Per ovviare dovevi creare e schedulare un processo di backup di comodo
che partiva qualche minuto prima del backup reale, il processo falliva
perche' non trovava il nastro, pero' faceva si che il nastro venisse
rilevato, per cui il backup reale che partiva poi funzionava.
Hanno risolto il problema con l'SP2, ora basta usare l'/um al termine
del comando di backup.
Stessa cosa per XP, basta usare l'/um e specificare di sovrascrivere i
dati sul nastro durante la creazione del processo di backup, il nastro
verra' sempre cancellato prima della copia.
Ciao
-- 
Francesco

 verra' sempre cancellato prima della copia.
Propongo un picchettaggio a Redmond per riavere il backup di NT!!!
Se non sbaglio (non ho sotto mano il mio fido NT) era della Seagate. :))
Seba

dimensione dell'archivio invece che diminuirla.
Esatto, con file mp3 perdi una parte dello spazio se comprimi (1.6gb
invece di due). C'e' da dire che con la compressione hardware il carico
della cpu e' bassissimo ma probabilmente su una macchina che ha svariate
centinaia di mhz (per non dire ghz) di cpu la cosa si nota poco.