Newsgroup: it.comp.os.linux.sys
Titolo: Linux e DAT

Ciao a tutti,
ho un server SuSE Linux 7.3 Kernel 2.4.16 che monta un'unità di backup HP
Surestore DAT 20/40 SCSI. L'unità funziona regolarmente eccezion fatta per
la compressione hardware. Sebbene  il comando
#mt -f /dev/st0 datcompression
restituisca
#Compression on
di fatto sembra che la compressione non funzioni. Il backup, che effettuo
con tar, si blocca a un certo punto con il messaggio
#Cannot write: No space left on device
Il cliente ha un totale di 25 GB di dati, e, a parte 1.3 gb di file zip e
~600 mb di MP3, il resto sono documenti office che dovrebbero comprimersi a
sufficienza. Se uso la compressione software (opzione -z di tar) il backup
termina infatti con successo. Tra l'altro quando l'unità era gestita da Win
tutto funzionava :-(
L'unità viene correttamente rilevata al boot, marca e modello preciso e
infatti scrive e legge perfettamente, ma la compressione non funziona.  Ho
letto su Web che la compressione software è rischiosa perché se un micron di
nastro è danneggiato, anziché consentire il restore di tutti i file non
danneggiati non consente il restore per nulla. Qualcuno ha qualche idea?
Ciao
Ste

 #mt -f /dev/st0 datcompression
e mt -f ... compression che ritorna ?
Davide

 ha scritto nel messaggio
news:am9nfu$3kbni$3...@ID-18487.news.dfncis.de...

#mt: invalid tape operation `compression'

dav...@yahoo.com
 ha detto...

Questo comando e` da dare ad ogni power-on del server oppure sono
comandi che il dat memorizza e mantiene finche` non gli vengono
cambiati con altri comandi?
-- 
Massimo  ;-)  | EMail: 
q-con...@iol.it
 * ICQ: 37930285
--------------> 
http://digilander.iol.it/MaQ
  BABYLON5  --> 
http://digilander.iol.it/babylon5
  *TRIBOL*  --> 
http://digilander.iol.it/usstribolo


E perche' mai questo dovrebbe accadere? Il file o e' recuperabile o non lo
e', indipendentemente dal fatto che contenga dati compressi o meno. L'unico
caso in cui puo' fare differenza e' se ti accontenti di un recupero
parziale, ma non vedo perche' lo escluderlo a priori nel caso si usi la
compressione software.
Sbaglio?
Alessandro.

 E perche' mai questo dovrebbe accadere?
Per la compressione hardware non so, ma per la compressione software, leggendo
dal device, anche se i blocchi danneggiati possono venire sostituiti,
(mettiamo) con dei blocchi con byte tutti a zero, sovente da quel punto in poi
non riesci piu' a decomprimere la stream di dati... quindi il resto viene
perso.
bye G.L.
--
La logica non attiene alla verosimiglianza delle ipotesi,
ma alla coerenza delle tesi con le ipotesi.


(tipico caso in cui invertendo i fattori il risultato cambia :-)
Quindi tar e' "robusto" alle perdite di parte dell'archivio mentre gzip non
lo e'. Per limitare ulteriormente i danni si potrebbe usare bzip2 che pare
che in questo senso sia un po' piu' robusto.
Alessandro
che sta imparando adesso ad usare la sua prima unita' nastro.


Nessuno ha qualche hint sul mio problema ? :-(


Forse la compressione e' effettivamente abilitata, ma non e' efficiente come
quella di gzip. In questo caso il problema e' mal posto.
Potresti provere a comprimere i singoli file con bzip2 o altro formato che
supporti il recovery dei file danneggiati e poi copiarne su DAT la versione
compressa.
Alessandro.