Newsgroup: it.comp.os.linux.sys
Titolo: tar su nastro: slack space?

Ho un nastro SCSI DDS3 su cui faccio backup con tar, e ho notato che
lo spazio effettivamente occupabile è molto meno di quello nominale.
Lasciamo da parte il discorso della datcompression hardware e del
filtro gzip di tar, che su dati già abbastanza compressi suppongo
abbiano un effetto limitato. Rassegnamoci ai 12 Gb nativi del DAT.
Volevo copiare sul nastro 11436288 KB, e la copia si è interrotta.
Il contenuto del nastro, che ho estratto a scopo diagnostico, era di
10254440 KB.
Possibile che un 12 GB si fermi a così poco? Quale potrebbe essere il
problema? Una sorta di slack space?
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 10254440 KB.
Io ho un dds3 che amanda mi ha riconosciuto cosi':
define tapetype mytape {
        comment "mytape without compression"
        lenght 11743 mbytes
        filemark 0 kbytes
        speed 2640 kps
}
quindi direi molto vicino ai 12Gb teorici , forse è colpa del nastro ,
controlla anche che la compressione hw sia effettivamente disabilitata
( mt -f /dev/st0 defcompression 0 )
xche' a volte a seconda dei modelli da' problemi.
ciao.
-- 
Fare l'amore con la propria moglie e' come sparare ad un'anatra morta.
                -- Da it.hobby.umorismo

 problema? Una sorta di slack space?
Ma sei sicuro che sian 12G? A me risultano 10G (e a se il conto e' come per
gli HD, 1MB=1000000 byte, 10254 MB sembrano proprio 10 GB).
Ciaotutti,
*


 ha scritto nel messaggio
news:2jo7hvF...@uni-berlin.de...


 A me vengono 9,78 Gb :P
Purtroppo i commerciali non sanno he 1Kb=1024byte, quindi suppongono che
sia come 1Kg=1000g...
Tutti i supporti magnetici (o almeno il 99%) in circolazione contano
1Kb=1000byte. Il divario si "allarga" contando in Mb (circa 5%) e in Gb
(circa 10%). Sui Tb il divario sara` sul 20%.
Bye.

controlla anche che la compressione hw sia effettivamente disabilitata
Proverò questa.


problema? Una sorta di slack space?
Ho fatto oggi una prova su un media e un sistema completamente
diversi.
Utilizzando Windows NT 4.0, un DLT Compaq 35/70 e 32 Gb di ZIP (quindi
non comprimibili)  il nastro da' "full" e non porta a termine il
backup. Se uso 29 Gb il backup va a buon fine.
Mi sa che la capacita' e' quella nominale non formattata da cui devi
sottrarre l'overhead della formattazione, cosi' come i dischi HD da
3"1/2 venivano dichiarati "2 Mb unformatted".
Generalmente questo non si nota perche' la compressione rende
irrilevante l'appesantimento della formattazione.
Ciao,
luigi

Proverò questa.
Senza datcompression ce l'ha fatta.


 Senza datcompression ce l'ha fatta.
inizio a sospettare che tutti i dds abbiano questo problema , almeno quelli
che ho io si comportano cosi' , praticamente con la compressione abilitata
il nastro dura meno..... bo'.
-- 
- Cosa dice la fatina ninfomane quando si appoggia sul naso di Pinocchio?
- Di' una bugia!  Di' una bugia!
                -- Massimo Ceccherini, al "Maurizio Costanzo Show"

 il nastro dura meno..... bo'.
Dalla mia esperienza se metti su dat un file gzip o bzip2 il risultato è
che il file per magia si ingrandisce di un 5-10%, cosa che in un
salvataggio normale (file compressi e non) si nota meno perchè lo spazio
occupato in più dai file compressi viene compensato dai file che si
comprimono.
Direi quindi che un salvataggio di un file da 12Gb conviene farlo senza
compressione, indipendentemente dal fatto che sia comprimibile o no.
Ciao,
Davide

 compressione, indipendentemente dal fatto che sia comprimibile o no.
si' , anche io ho la compressione disattivata dappertutto e tra l' altro
credo che impatti anche sul transfer-rate.
bye.
-- 
Io guardo alla vita come se fossi il capitano del Titanic.  Forse non
arrivero' dove voglio andare, ma ci vado in prima classe.
                -- Art Buchwald