Newsgroup: it.comp.os.linux.sys
Titolo: tape dds4: solo  10 GB ?

Buondi a tutti,
  ho un problemino con un DAT.
Spero mi possiate aiutare, io di DAT non me ne intendo gran che.
Il DAT e' DDS4 (20/40 GB) ma non riesco ad archiviare piu' di 15 GB.
Oggi addirittura, capita che non superi i 10 GB .
E' normale ?
Io salvo dei file gz. Nel caso di oggi sono 30 file da 300 MB l'uno.
Il modello del tape:  seagate dat 06240-XXX (Rev: 8110)
Ne ho ben 3, tutti con lo stesso problema.
Sono forniti coc IBM Netfinity 5000 e 5100.
Sono nastri 20/40 GB, quindi almeno 18 GB (son gentile, dai)
dovrebbe archiviarli.
E' normale questa "sottocapienza" ?
Cosa mi sfugge ?
Un aggiunta, magari vi torna utile.
Quando eseguo il tar mi appare questo messaggio:
   st0: Block limits 1 - 16777215 bytes
Io purtroppo non ho avuto modo di indagare a fondo;
non cerco il piatto caldo (anche se...), 
mi accontento intanto di un suggerimento .
grazie a tutti
ciaooo

 E' normale ?
No, non lo e'. Prova con un nastro nuovo.
Davide
-- 
Q: Why is Microsoft's Product Support a failure?
A: Because Microsoft needs a Support Group instead.

Davide
gia' fatto ma non cambia nulla.
per i 15 GB, ormai ho fatto il callo, sono 3 anni che
si comporta cosi.
di norma, quando GB non compressi si riescono effettivamente 
ad archiviare ?
io uso il tar nel modo piu' semplice:
  tar -cvf /dev/st0 ./
a volte ci metto anche l'opzione -M
grazie per l'aiuto 
ps: "The Fuck-up Fairy"  he he he 
:)

 ad archiviare ?
se il tape e' 20/40 dovrebbero entrarcene almeno 18, oltre potrebbe
essere un problema.
Davide
-- 
...A Microsoft spokesperson said, "while fighting software piracy is good
for our business, highway robbery is our business." 
   -- From a Slashdot.org post

io ho un caricatore dds4 , ogni nastro tiene + o - 18~19 gb.
non è che usi un nastro dds3 ?
-- 
Che differenza c'e'...
        tra palle e coglioni?
        Palle sono quelle che si raccontano;
        coglioni sono quelli che ci credono.
                -- Da it.hobby.umorismo

    st0: Block limits 1 - 16777215 bytes
Ecco, questo era un problema che mi dava quando usavo la compressione del
DLT, infatti quando si usa viene richiesto il "variable block size" e per
qualche motivo che non ho indagato il tar si trova a sprecare un sacco di
spazio.
Da quando ho disattivato la compressione con i comandi defdensity e
compression di mt dico a tar di usare un blocksize di 10240 bytes e va.
Non so se puo' essere il tuo caso, ma tentar...
-- 
Mario "Reliant" Pascucci
"From" field altered. Please use ilpettegolo(a)
yahoo.it
 for private mail.
http://ilpettegolo.altervista.org/


Io mi ritrovo, credo, con lo stesso problema..
Compression on.
tar: /dev/st0: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now
la cosa curiosa è che il tar è arrivato un giorno a >13GB e ha dato questo
problema, ridimensionato il tar a ~9GB continua a darlo...
D!



Prova ad usare l'opzione -b 32 di tar, ossia blocksize = 16384 bytes,
dopo aver disabilitato la compressione del nastro con 
mt -f /dev/st0 setdensity 0xNN (per quale valore mettere: mt densities)
oppure
mf -f /dev/st0 compression 0
per disattivare la compressione nativa del nastro, dipende dal tipo di
nastro, il DLT ha un codice di densita' specifico per la compressione, il
DAT mi pare che voglia invece il comando di compressione off.
Se non dovesse gradire, prova altri valori del blocksize.
Il problema e' che non c'e' modo durante la scrittura su nastro di sapere
quanto spazio rimane (o meglio non lo puo' sapere il tar) e la
compressione complica le cose perche' diventa imprevedibile il tasso di
compressione, per cui se vai a salvare file con la compressione gzip di
tar e poi con la compressione del nastro, hai l'effetto "espansione" ossia
vai ad occupare piu' spazio. La cosa la puoi facilmente verificare se fai
un tar di file zip e poi obblighi bzip2 a ricomprimere il tar cosi'
ottenuto: paradossalmente ottieni molto probabilmente una maggiore
occupazione di spazio. 
HTH
