Newsgroup: it.comp.os.linux.sys
Titolo: Richiesta di aiuto: unità DAT

Buongiorno a tutti.
Stò cercando aiuto per un problema insorto con l'utilizzo di unità DAT
SCSI DDS4 per il backup dei dati, sotto Debian con kernel 2.6.
Per la scrittura dei dati viene utilizzato un semplicissimo "tar".
L'installazione del controller SCSI e dell'unità DAT è sempre avvenuta
senza alcun problema, con il sistema che ha sempre rilevato
correttamente tutti i componenti. Non solo, anche l'operazione di
copia vera e propria avviene all'inizio sempre regolarmente,
sfruttando appieno i 20Gb non compressi a disposizione sul nastro.
La cosa che mi ha fatto impazzire, tuttavia, è che dopo un tempo non
determinato, nell'ordine di settimane o giorni o mesi, il sistema
smette di funzionare, nel senso che da un giorno all'altro il "tar"
esce con un errore del tipo "Sono riuscito a scrivere solo 350Mb e non
c'è più spazio. Esco".
Ripeto, da un giorno all'altro, senza che il sistema sia stato toccato
o modificato, e il problema poi rimane costante.
Tutte le prove che ho effettuato, ricompilando il kernel, modificando
il blocksize, pulendo le testine, etc etc, non hanno portato a nulla.
Il problema si è verificato su sistemi differenti, in tempi diversi,
con unità DAT di tipo diverso.
Qualcuno ha mai sperimentato un comportamento del genere?
Qualche suggerimento?
Saluti.
Marco

 smette di funzionare, nel senso che da un giorno all'altro il "tar"
Magari qualche log di errori sarebbe utile.
Ma quando sento parlare di "mesi", mi viene in mente che le cassette si 
devono cambiare piů spesso. E non vanno reciclate.
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?


Giusto. Sono stato un po' troppo vago. Allora vediamo:
1) Ho parlato di "mesi", perchè il problema è nato tipo 2 mesi dopo il
setup del sistema (nuovo), oppure dopo due settimane, in altri casi
magari dopo 10 giorni. La cosa incredibile è che non riesco a vedere
uno schema, un evento scatenante, è totalmente casuale.
2) Uno dei primi tentativi è stato quello ovviamente di sostituire i
nastri, oltre ad effettuare diverse pulizie delle testine con
l'apposita cassettina. I nastri utilizzati per le prove successive
erano comunque sempre nuovi e non riciclati. La marca usata è TDK
oppure Maxell.
3) Il controller usato è un Tekram DC390U2B Ultra2LVD/SE, il drive è
un HP:
imb:~# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 03 Lun: 00
  Vendor: HP       Model: C5683A           Rev: C111
  Type:   Sequential-Access                ANSI SCSI revision: 02
E' collegato con cavo flat U160 ed opportunamente terminato.
Nel sistema è installato il pacchetto mt-st:
imb:~# dpkg -l | grep mt-st
ii  mt-st                   0.8-1                      Linux SCSI tape
driver aware magnetic tape c
Il supporto per il controller è compilato staticamente nel kernel (ma
ho provato anche come modulo).
4) Ecco l'errore tracciato dal semplice script di backup:
Iniziato: ven feb 10 04:52:23 CET 2006...
tar: Removing leading `/' from member names
tar: Removing leading `/' from hard link targets
Total bytes written: 368271360 (352MiB, ?/s)
tar: /dev/st0m: Impossibile write: No space left on device
tar: Errore irrimediabile: esco
Terminato: ven feb 10 06:48:00 CET 2006...
Questo è lo script:
imb:~# cat /usr/local/bin/backupDat.sh
#!/bin/bash
/etc/init.d/mt-st restart
DEVICE="/dev/st0m"
STATUSFILE="/tmp/backupDat.status"
EMAIL="
admi...@foo.com
"
BACKUP="/var/lib/backuppc"
mt -f $DEVICE rewind > $STATUSFILE 2>&1
echo "Iniziato: `date`..." >> $STATUSFILE 2>&1
tar -cf $DEVICE --totals $BACKUP >> $STATUSFILE 2>&1
echo "Terminato: `date`..." >> $STATUSFILE 2>&1
mail -s "BackupDat del `date`" $EMAIL  < $STATUSFILE
Questa è la configurazione del drive caricata all'avvio del sistema e
di ogni backup:
storm:~# cat /etc/stinit.def
# A compressing DAT (DDS-4)
manufacturer=HP model=C5683A
{
scsi2logical=1
buffer-writes
read-ahead
async-writes
can-bsr can-partitions auto-lock
mode1 blocksize=0 compression=1
mode2 blocksize=1024 compression=1
mode3 blocksize=0 compression=0
mode4 blocksize = 1024 compression=0
}
5) Sottolineo ancora una cosa: il problema compare improvvisamente,
cioè il backup funziona perfettamente per un certo periodo di tempo, e
poi comincia il comportamento di cui sopra, senza che il server sia
stato aggiornato, riavviato o qualsiasi altra cosa. Ho ovviamente
pensato anch'io che, essendo una cosa che compare nel tempo, potesse
essere legata ai supporti, ma l'evidenza non conferma. Anche i drive
sono assolutamente nuovi: spacchettati ed installati sul sistema,
nuovo anch'esso (piattaforma Intel P4, chipset Intel), come pure il
controller, i cavi ed il terminatore. Non mi sento di puntare il dito
sul drive: è uno standard diffusissimo, utilizzato da diversi vendors,
le varie unità sono state acquistate in periodi diversi,  il problema
è sorto anche con un SONY SDT-11000, mentre almeno un sistema con il
drive HP non mi ha mai dato problemi.
Help....
Marco

 
[ some data skipped .... SNIP .... ]
perche' non controlli cosa dice il kernel quando esce l'errore sul tar? 
spesso potrebbe essere un problema di cavo e magari il kernel mette off-line
la periferica scsi per troppi errori.
Andrea

Andrea
Grazie del suggerimento. Cercherò di controllare, tuttavia come può
verificarsi, sia pure in tempi diversi ma nell'arco di 3-4 mesi, lo
stesso problema su vari sistemi?
Stò forse sbagliando qualcosa nell'accoppiare i vari componenti, tali
da rendere la catena SCSI instabile?
Mah...
Marco

 Mah...
un altra volta avevo un controller 2100S adaptec raid U160-LVD che
riconosceva i dischi come voleva lui e ho scoperto che dovevo aggiornare i
firmware dei dischi.
in questo caso non posso che consiglarti di lucidare bene la sfera di
cristallo, spolverare il libro dei riti celtici, seguire un corso di
pratica voodoo, bere un po' di pozione magica di asterix e fare qualche
sacrificio al dio Google. :) 
ah, se poi ti scappano le SANTE BESTEMMIE DEL SISTEMISTA cerca almeno di
sfogarti lontano da orecchie indiscrete, ok? :)
ciao
 Andrea

 Andrea