Avanti Indietro Indice

11. FAQ: domande relative all'«utilizzo di Ftape»!

11.1 Quanto va veloce Ftape?

È possibile ottenere velocità di backup e ripristino abbastanza rispettabili con Ftape: con un Colorado DJ-20 ed un controller Adaptec 1542CF sono state misurate delle velocità di trasferimento continuative di 4.25MB/min (senza compressione) con un archivio tar da 70MB, mentre si stava confrontando l'archivio sul nastro con i dati su di un disco IDE. La velocità di Ftape dipende fortemente dalla velocità di trasferimento del proprio FDC: l'AHA1542CF è un FDC di tipo "post-1991 82077" che permette di inviare 1Mb/s di dati all'unità. Se si possiede un FDC che permette di spedire 500kb/s di dati, si otterrà una velocità di trasferimento dimezzata (beh, ovvio).

11.2 Quando scrivo su alcuni dei miei nastri, sembra che perda un sacco di tempo a ``lustrarsi le scarpe'' o nel riposizionamento, invece di trasferire dati. C'è qualcosa che non va nel mio sistema?

Ci sono stati un paio di casi di ``lustramento di scarpe''. Questo accade quando il nastro sembra correre avanti ed indietro senza fine. Ciò è stato notato con un Jumbo 250 (<74407.3051@compuserve.com>) e con uno Iomega 250 Ditto Insider (<tom@opus.cais.com>). Nell'ultimo caso si stava utilizzando Linux ELF con hard-disk SCSI (connesso ad un Adaptec 1542cf). Pregerei di contattarmi nel caso si abbia un aggiornamento al riguardo.

<dall'Ftape-HOWTO>

Probabilmente no. Se si sta eseguendo il backup di un gran numero di file di dimensione inferiore ai 2kB, bisognerà abituarsi a conviverci. In questo caso il riposizionamento è causato da un accesso spropositato al file system. Se si sta eseguendo il backup di file di sistema normali, questo può essere dovuto a sporco o stiratura del nastro della cartuccia. Con una semplice ritensionatura del nastro tutto dovrebbe sparire. Provare con 

ftmt -f /dev/zqft0 reten

per ritensionare il nastro. Se la ritensionatura non risolve il problema e accade solo con certi nastri, può essere opportuno sostituire il nastro in questione.

<risposta di Tim Jones>

Se si utilizza afio come strumento di backup, è possibile fargli scrivere un gran numero di buffer in un colpo solo utilizzando il flag -c. Utilizzare un valore opportuno in modo da fornire dati sufficienti per molti dei singoli passaggi punto-a-punto sopra il nastro. Per il mio sistema, le seguanti impostazioni vanno abbastanza bene, in quanto fanno fermare il nastro, a sistema scarico, un numero di volte relativamente basso ad ogni passaggio: 

find /usr/local -xdev -print | afio -o -v -f -b 10240 -c 800 /dev/qft0

Nel mio caso sto scrivendo 800x1024 byte per ogni scrittura sul nastro, cioè cira 8MB.

Non ho fatto molte esperienze con queste impostazioni, cosí qualcuno potrebbe volerne cercare di migliori.

Probabilemente altre utility di backup possono essere modificate per utilizzare una tecnica simile.

<risposta di Michael Hamilton>

Il tar di GNU non utilizza i buffer in questo modo. Il programma di backup commerciale bru è in grado di trattare buffer multipli utilizzando memoria condivisa; questo funziona solo quando si sta scrivendo archivi compressi con bru (indipendentemente dal fatto che si stia utilizzando la compressione di Ftape).

Un altro modo per sopperire al problema potrebbe essere quello di utilizzare piú buffer DMA nel driver Ftape del kernel: 

mt -f /dev/qft0 setdrvbuffer $((6*32786))

$((6*32786)) dovrebbe venir espansa dalla propria shell quando se ne utilizzi una Bourne-compatibile. Questo produce un impatto negativo sulla memoria di sistema: i buffer DMA di Ftape non possono essere utilizzati da nessun'altra parte del kernel, né da nessun'altra applicazione. E la memoria contenente il kernel non può essere messa nella partizione di swap. Se si decidesse di utilizzare questo tipo di bufferizzazione multipla, è conveniente scaricare il driver non appena il suo utilizzo è terminato.

<risposta di Claus Heine>

11.3 Devo far ripartire il mondo DOS per formattare i nastri?

No, se si sta usando l'ultima versione dei driver di Ftape disponibile all' home-page di Ftape.

Per formattare un nastro QIC-80, TR-1, TR-3, QICWide 3010 o 3020, procurarsi l'ultima versione di ftape e l'ultima versione del pacchetto ftape-tools (dallo stesso sito) e leggere la documentazione dell'utility ftformat inclusa nel pacchetto ftape-tools.

Comment

Non provare a formattare nastri Ditto 2GB.

Comment

Non provare a formattare nastri Ditto Max o Max Pro.

<risposta di Tim Jones e Claus Heine>

11.4 È possibile formattare nastri Ditto 2GB con ftape?

Non è possibile formattare nastri Ditto 2GB con unità a nastro Ditto 2GB, cosí come non è assolutamente possibile riformattare nastri Ditto 2GB in modo tale da poter essere utilizzati ancora da unità a nastro Ditto 2GB.

Questa è una limitazione hardware dell'unità a nastro Ditto 2GB. Non c'è possibilità di aiuto a livello software, cioè non è una mancanza di ftape.

11.5 È possibile formattare nastri Ditto Max o Max Pro con ftape?

No, il Ditto Max non può formattare nastri.

Questa è una limitazione hardware dell'unità a nastro Ditto 2GB. Non c'è possibilità di aiuto a livello software, cioè non è una mancanza di ftape.

11.6 Ftape rileva piú settori danneggiati con nastri QIC-3020 di quanto non faccia DOS.

Se si presta attenzione alla differenza, si noterà che Ftape rileva sempre 2784 settori in piú di DOS.

Il numero che Ftape riporta è corretto (ovviamente :-). Tutti i nastri QIC-3020 correttamente formattati hanno 2784 settori in posizioni predefinite che sono marcati nella mappa dei settori danneggiati. Quotando dalle specifiche:

Le tracce 5,7,9,11,13,15,17,19,21,23,25 e 27 comprese nei 4 segmenti o dell'EOT o del BOT sono disposte per aumentare i tassi d'errore per via delle hole imprints [impronte del buco?]. Per questo motivo queste regioni devono essere mappate come danneggiate nel momento della formattazione ed ascritte nella mappa dei settori danneggiati per indicare che tutti i settori all'interno dei segmenti identificati sono danneggiati.??

Questo fornisce 12 tracce * 2 * 4 segmenti * 29 settori = 2784 settori.

Cosí Ftape preferisce riportare il numero effettivo di settori che non possono essere utilizzati sul nastro, mentre DOS fornisce un numero piú ottimistico indicando una migliore qualità del nastro. Il comportamento di Ftape, comunque, potrebbe cambiare in futuro per rilevare una formattazione corretta e mostrare due numeri separati. In ogni caso a questo, per ora, non è riservata un'alta priorità.

I nastri QIC-3010 sono simili ai QIC-3020 al riguardo.

<dall'Ftape-HOWTO>

11.7 Non ci sono problemi se non sento il nastro muoversi quando impartisco un comando fsf o bsf con mt?

No. L'unità semplicemente aggiorna un contatore interno quando riceve questi comandi. Il nastro dovrebbe muoversi alla posizione corretta con l'accesso in lettura o scrittura all'unità successivo.

<dall'Ftape-HOWTO>

11.8 Perché il mio programma di backup XYZ si lamenta di errori di tipo ``Invalid argument'' [argomento non valido]?

zftape richiede che i dati vengano scritti come multipli della dimensione dei blocchi minima fissata. Questo è un comportamento tipico per una periferica a nastro. Ci sono tre modi per eliminare questi errori:

È opportuno leggersi la sezione ``Tape blocks'' del manuale (utilizzare l'indice analitico per andare direttamente alla sezione relativa).

Quando si utilizza la compressione interna di GNU tar con versione di GNU tar antecedente la tar-1.12, è necessario lanciare tar con l'opzione --block-compress impostata su re-block. In caso contrario tar comprimerà i dati che legge e li scriverà in porzioni arbitrarie sul nastro.

Eesempio: 

tar -czvf /dev/qft0 --block-compress /etc

Attenzione: non si dovrebbe utilizzare la compressione interna di tar con grandi backup, in quanto ciò produce un enorme blocco compresso del flusso di dati. Se un tale archivio viene rovinato proprio all'inizio, è veramente difficile ripristinarlo.

<risposta di Claus Heine>

11.9 Errori I/O e FDC: alcune spiegazioni.

Se si ottengono i seguenti messaggi, questo è ciò che fa per te!

La spiegazione:

``FDC'' significa ``Floppy Disk Controller'' [controllore per dischi floppy]. Il problema è che il proprio controller floppy deve essere in grado di supportare qualcosa chiamato ``perpendicular mode'' [modo perpendicolare], per essere in grado di leggere e scrivere cartucce QIC-3020/QIC-3010 (cioè cartucce TR-3). Per quanto ne sappia, tutti gli FDC che sono in grado di trasferire dati ad almeno 1Mb/s supportano anche il ``perpendicular mode'' (l'aggettivo ``perpendicolare'' si riferisce alla direzione della magnetizzazione delle particelle ferro magnetiche sul nastro).

Questo significa che è necessario procurarsi un altro FDC. Oppure dare un'occhiata in qualche negozio per computer e chiedere di una scheda di controllo I/O che sia in grado di supportare floppy da 2.88MB (che implica un velocità di trasferimento di 1Mb/s ed il modo perpendicolare).

È possibile anche procurarsi i cosiddetti ``controller ad alta velocità'', che supportano anche trasferimenti da 2Mb/s. Questi controller sono basati su un FDC Intel 82078. Iomega vende tali schede sotto il nome di ``Ditto Dash''. Penso che anche Exabyte venda i suoi controller da 2Mb/s separatamente, mentre Seagate fornisce l'unità TR-3 (cioè TST-3200) con questi controller inclusi.

<risposta di Claus Heine>

11.10 Perché ottengo errori del tipo «/dev/qft0: No such device» [/dev/qft0: nessun device come questo]?

Supponiamo che il problema sia il seguente. Il modulo Ftape è caricato correttamente nel kernel: 

/usr/src/ftape-3.03b-970603# lsmod
 Module         Pages    Used by
 ftape             22          0
ma accade che: 
$ ftmt -f /dev/qft0 status
ftmt: /dev/qft0: No such device

La soluzione: è necessario anche caricare il modulo zftape.o. Con Ftape-3.* il modulo ftape.o non implementa l'interfaccia VFS. Questo è fatto da zftape.o.

<risposta di Claus Heine>

11.11 Ottengo un ``device busy'' [periferica occupata] quando eseguo backup multipli su di un nastro utilizzando alcuni script.

I messaggi di ``periferica occupata'' possono verificarsi mentre le file di periferica di Ftape sono ancora mantenute aperte da alcuni programmi. Non appena la chiamata di sistema close() viene completata, il flag di occupato viene azzerato. Potrebbe darsi che bru, o altri programmi, abbiano eseguito un fork di un figlio che ritarda a morire?

Sí, questo riproduce il problema: 

tar -cvvzf /dev/nqft0 --block-compress ; mt rewind

È possibile omettere --block-compress se si sta utilizzando un versione di GNU tar piú recente.

Comunque questo non è un baco di Ftape. Sembra che il processo tar genitore esca prima che suo figlio abbia chiuso il device del nastro. So comunque, per aver studiato il codice di tar alcuni anni fa, che tar attende correttamente che il proprio genitore muoia.

In ogni caso, il messaggio di occupato significa semplicemente che la variabile ``busy'' [occupato] è ancora mantenuta ad un valore logico 1 (zftape/zftape-init.c), e questo significa semplicemente che c'è ancora un processo in giro che tiene il device del nastro aperto.

Penso di aver capito il motivo (solo nel caso di tar in quanto di questo ho il codice sorgente).

Se si utilizza tar con la compressione abilitata, allora viene eseguito un fork di un figlio che diventerà il compressore tramite l'esecuzione di gzip o qualcos'altro. Prima della chiamata a execlp(), il figlio eseguirà un fork di un nipote di suo padre tar. Questo nipote eseguirà l'effettvo lavoro di I/O sul nastro. 

tar - fork() - scrive verso il figlio di tar
        |
  figlio di tar - fork() - gzip (eseguirà un pipe al nipote di tar)
                    |
              nipote di tar - apre l'archivio

Ora, il genitore tar aspetta che suo figlio muoia. gzip sicuramente non aspetta il nipote in quanto gzip è il risultato di un execlp().

Ciò che non so è se il nipote dovrebbe essere implicitamente aspettato dal genitore tar o se la funzione wait() aspetta anche i nipoti.

Comunque questo sembra essere il problema: il genitore tar è uscito mentre suo nipote è ancora occupato a chiudere l'archivio. In condizioni normali difficilmente si noterà questo problema se la funzione close() viene portata a termine velocemente (cioè file regolari, periferiche a blocchi e magari altri device per nastri?), ma non è un baco di Ftape, mentre lo è nei programmi di backup, nel kernel o forse nel codice d'uscita delle libc.

Non so se le considerazione fatte in precedenza si possono essere applicate anche a bru. Se non ci sono nipoti e il processo padre attende in maniera corretta suo figlio, allora non ci dovrebbero essere problemi.

<risposta di Claus Heine>

11.12 Come faccio a... con tar?

Queste sono propriamente domande per tar: si prega di leggersi la pagina man e la pagina info realtive. Se non sono installate sul sistema, provare con 

tar  --help 2>&1 | less

Se la propria versione di tar è la v1.11.1 o precedente, si consideri l'opportunità di aggiornarla alla v1.11.8. Questa versione può chiamare GNU zip direttamente (cioè supporta l'opzione -z) e possiede un elaborato help incluso. Inoltre tutto può essere compilato in ambiente Linux.

<dall'Ftape-HOWTO>

11.13 Che dimensione per i blocchi devo utilizzare con tar?

Se si fa uso della compressione (ed anche piú in generale), può tornare a proprio favore specificare a tar che deve spezzettare l'uscita in blocchi grossi. Poiché Ftape taglia i dati in blocchi da 29kB, un ``-b58'' dovrebbe essere ottimo.

«Perché 29kB?» mi sembra di sentir gridare. Beh, lo standard QIC-80 specifica che tutti i dati debbano essere protetti da un Error Correcting Code [codice per la correzione d'errore] (ECC). Il codice specificato nello standard QIC-80 è conosciuto come codice Reed-Solomon (R-S). Il codice R-S considera 29 byte di dati e genera 3 byte di parità. Per aumentare le prestazioni del codice ECC, i byte di parità sono generati su 29 settori da 1kB. Cosí Ftape prende 29kB di dati, aggiunge 3kB di parità ECC e scrive 32kB sul nastro alla volta. Per questa ragione Ftape scriverà e leggerà sempre blocchi da 32kB per essere in grado di rilevare (e correggere) eventuali errori.

Se si possiede una spiccata curiosità e si vuole conoscere di piú, è possibile dare un'occhiata ai file ecc.c ed ecc.h per una spiegazione del codice e un riferimento a testi sui codici Reed-Solomon.

<dall'Ftape-HOWTO>

11.14 Dove posso trovare i binari, i sorgenti e le pagine man di tar, mt, cpio e dd?

Tutti questo strumenti sono stati sviluppati dal progetto GNU ed i sorgenti (cosí come le pagine man) possono essere prelevate da praticamente ogni sito ftp nel mondo (inclusi ftp.funet.fi, tsx-11.mit.edu, e sunsite.unc.edu). In ogni caso possono essere prelevati dal sito ufficiale GNU: prep.ai.mit.edu [18.71.0.38]:/pub/gnu. Le ultime versioni (ad oggi 12 settembre 1996) sono: 

cpio:   2.4.2 (cpio-2.4.2.tar.gz)
dd:     3.13 (fileutils-3.13.tar.gz)
mt:     2.4.2 (cpio-2.4.2.tar.gz)
tar:    1.11.8 (tar-1.11.8.tar.gz)
gzip:   1.2.4 (gzip-1.2.4.tar.gz)

Tutto quanto può essere compilato in ambiente Linux successivo alla versione v1.0.4, libc v4.5.19 e gcc v2.5.8.

<dall'Ftape-HOWTO>

11.15 Se utilizzo la compressione dell'unità a nastro, è sbagliato sfruttare anche la compressione di zftape. O sarebbe meglio non utilizzare la compressione dell'unità e lasciare che faccia tutto zftape?

Non è cosí sbagliato come utilizzare la compressione due volte (che sarebbe il caso in cui si utilizza la compressione dell'unità assieme alla compressione di ftape), ma non ha senso. Non si guadagna un maggior compressione, ma solo cicli di CPU sprecati.

La compressione dell'unità dovrebbe essere abbastanza sicura, in quanto l'unità comprime singoli file, a differenza di tar -czf..., che fa dell'intero flusso di dati un grande blocco compresso. Questa, infatti, è una pessima idea con backup seri, in quanto un singolo byte rovinato all'inizio dell'archivio può rendere inutilizzabile l'intero archivio, o, almeno, ne rende piuttosto difficoltoso un suo recupero.

<risposta di Claus Heine>

11.16 Com'è la compressione di zftape a confronto di quella, diciamo, di gzip -9?

gzip -9 è migliore (cioè si può ottenere una maggiore compressione). La compressione di zftape è paragonabile al programma Un*x compress, ma dovrebbe essere piú veloce, e lo è rispetto a gzip.

<risposta di Claus Heine>

11.17 Non utilizzo la compressione, ma sento che l'interfaccia zftape se ne sta andando. Cosa posso fare?

Si utilizzi l'interfaccia zftape, senza caricare il modulo zft-compressor. Il device allora diventa /dev/qft0.

<risposta di Tim Jones>

11.18 Ftape dice «This tape has no 'Linux raw format'» [questo nastro non è nel ``formato elementare Linux''].

Si ottiene questa lamentela se non si è cancellato il proprio nastro appena formattato. Questo accade perché Ftape si aspetta un ``magic header'' [intestazione magica] sul nastro per sapere di essere in grado di interpretare il segmento di intestazione a suo modo (cioè con i marcatori di file). Per eliminare il problema, impartire il comando: 

mt -f /dev/nftape erase

<dall'Ftape-HOWTO>

11.19 Posso scambiare nastri con qualcuno che utilizza il DOS?

No. Il software per DOS è conforme alle specifiche QIC-80 circa la disposizione del filesystem di DOS e non dovrebbe essere un grosso problema scrivere un programma che possa leggere e scrivere il formato DOS. Infatti, scommetto che creare un'interfaccia utente graziosa sarebbe un problema piú grande.

<dall'Ftape-HOWTO>

11.20 Come funziona mt eom quando si comincia a sovrascrivere un nastro dalla metà?

Per inciso, EOM è l'acronimo di ``End Of recorded Media'' [fine del supporto di registrazione], la posizione esattamente dopo tutti i dati già registrati sul nastro.

Non si può utilizzare i ``file'' del nastro come file di un ordinario filesystem. In linea di principio, un nastro non permette nient'altro che aggiungere nuovi dati in coda all'EOM. Ciò nonostante, se ci si posiziona proprio nel mezzo dei dati già registrati e si comincia a scrivere, allora l'unità prima cancella tutti i file successivi (cosí da spostare l'EOM alla posizione effettiva) e poi comincia a scrivere. Cosí il nuovo EOM, terminato il processo di scrittura, si trova dopo i dati appena registrati. Una delle conseguenze di quanto sopra, è che, ovviamente, quella scrittura sul nastro nel mezzo dell'area già registrata è distruttiva, nel senso che non solo sovrascrive il ``file'' sopra il quale la testina era posizionata, ma cancella anche tutti i file che seguono.

<dall'Ftape-HOWTO>

<risposta di Claus Heine>

11.21 Quando eseguivo dei backup prima di utilizzare taper, sotto ftape 2.0.29 la mia unità non supportava l'fsf, mentre sotto il nuovo zftape lo supporta. Perché dovrebbe e cos'è esattamente l'fsf?

Probabilmente non funzionava prima perché non si era utilizzato un 

mt -f /dev/rft0 erase

prima di scrivere i dati sulla cartuccia. Questo non è piú necessario.

Ma ``mt fsf'', cosa significa? Le unità a nastro non registrano i file in modo che si possa utilizzare un 

cp qualche_file /dev/la_mia_unità

o in modo da essere capaci di montare un'unità a nastro cosí come si monta un hard-disk. Non è possibile fare altro con un'unità a nastro se non scrivere dati in maniera sequenziale su di essa.

Poiché queste è abbastanza scomodo, qualcuno ha inventato qualcosa che è conosciuto con il nome di file mark o eof mark (eof è l'acronimo di ``End Of File'' [fine del file]). Questi marcatori non separano i file di cui è stato fatto il backup sull'unità a nastro, ma separano solo i blocchi di dati (qualsiasi cosa i dati possano rappresentare).

Normalmente i driver del kernel dell'unità a nastro si occupano di scrivere questi marcatori di file quando il device del nastro viene chiuso, cioè con 

tar -cf /dev/nqft0 /bin
tar -cf /dev/nqft0 /etc
mt -f /dev/nqft0 rewind

si otterrebbe un backup di tutti i file sotto /bin ed /etc. Quando il primo tar termina, il driver del kernel si occuperà della scrittura di un marcatore di file sul nastro alla posizione corrente e, quando termina il seconfo processo tar, un altro marcatore di file viene scritto sulla cartuccia in quella posizione. Ora, il motivo di questi marcatori di file consiste nel fatto che è possibile saltare fra archivi differenti presenti sul nastro piú velocemente di come si potrebbe fare con un rilettura sequenziale dei dati.

I comandi che fanno questo sono:

mt fsf

cvanzamento veloce al prossimo marcatore di file verso l'EOT (End Of Tape [fine del nastro]),

mt bsf

avanzamento veloce al prossimo marcatore di file verso il BOT (Begin Of Tape [inizio del nastro]).

Cosí, per estrarre il secondo archivio nell'esempio precedente, non è necessario rileggere il primo archivio, ma procedere come segue: 

mt -f /dev/nqft0 rewind
mt -f /dev/nqft0 fsf
tar -xvf /dev/nqft0

<risposta di Claus Heine>

11.22 Qual'è esattamente la differenza fra ftape e zftape?

Quando Ftape era ancora giovane, c'erano due versioni dei driver per unità a nastro, una delle quali venne chiamata zftape per via della sua compressione interna eseguita al volo e trasparente all'utente. Se questa sia una caratteristica positiva od un baco (in quanto non strettamente necessario che sia fatta dal codice del kernel) è un'altra questione. Comunque sia, l'interfaccia ioctl e l'uso dei marcatori di file forniti da zftape erano notevolmente superiore e con meno bachi. Inoltre zftape permette di utilizzare cartucce a nastro per floppy con differenti sistemi operativi. Beh, non è possibile scambiare dati, ma ftape non sovrascriverà i volumi creati con il proprio programma Windoze e viceversa.

Oggi giorno Ftape è il nome dell'intero pacchetto di driver per unità a nastro via controller floppy, ed ftape.o è il nome del file del modulo kernel che implementa il supporto hardware a basso livello. zftape ha cessato di esistere come un pacchetto separato, mentre la nuova versione di Ftape (da ftape-3.00) contiene un modulo zftape.o che si appoggia ad ftape.o (cioè diventa necessario caricare entrambi i moduli per essere in grado di accedere alla propria unità) e implementa l'interfaccia del sistema di file e le caratteristiche avanzate della precedente versione di zftape.

<risposta di Claus Heine>

11.23 Qual'è la differenza fra una periferica riavvolgente ed una non-riavvolgente?

Beh, i file delle periferiche a nastro riavvolgenti riavvolgono il nastro al BOT (Begin Of Tape [inizio del nastro]), cioè 

tar -cvf /dev/qft0 /bin

riavvolgerà la cartuccia quando il lavoro di tar è terminato. Invece 

tar -cvf /dev/nqft0 /bin

non riavvolgerà la cartuccia e lascierà la testina di lettura/scrittura nella possizione corrente.

Periferiche riavvolgenti dovrebbero essere utilizzate quando si effettuano backup singoli; periferiche non-riavvolgenti dovrebbero essere utilizzate quando si eseguono backup multipli, a meno che non ci sia bisogno di tutto lo spazio fino all'EOM (End Of recorded Media [fine del supporto di registrazione]) prima di aggiungere un altro archivio.

Le periferiche non-riavvolgenti devono essere utilizzate quando si invia un qualsiasi comando di movimento all'unità a nastro, come 

mt -f /dev/nqft0 fsf

perché, quando il processo mt termina, l'unità a nastro viene chiusa e ciò comporta un riavvolgimento della cartuccia con le periferiche riavvolgenti.

<risposta di Claus Heine>

11.24 C'è qualcuno che potrebbe dirmi come utilizzare mt per riavvolgere la mia unità TR-3 dopo aver registrato un archivio con zftape, cosí da poterlo verificare?

Beh, dipende. Se il nastro è ancora posizionato all'interno del volume appena scritto, un ``mt bsf 1'' (o equivalentemente ``mt bsf'') farà ritornare il nastro proprio all'inizio di quel volume (questo è il modo in cui tar --verify lavora). Se il nastro è già posizionato dopo il marcatore di file che indica la fine dell'ultimo volume scritto, allora è neccessario impartire un ``mt bsf 2''.

La logica che sta dietro a tutto ciò è la seguente: Il ``contatore MTBSF'' viene decrementato di tante unità quanti sono i marcatori di file contati, il nastro viene fermato e successivamente posizionato sull'EOT dell'ultimo marcatore di file saltato. Questo significa che un mt bsf 2 posizionerà il nastro esattamente all'inizio del precedente volume.

<risposta di Claus Heine>

11.25 ``Non-riavvolgente'' significa che «non si riavvolge automaticamente», giusto? Non sta ad indicare che sotto nessuna circostanza non si riavvolgerà, vero? Ho provato ad utilizzare /dev/zqft0 ed il nastro è stato subito riavvolto.

Corretto: ``auto-riavvolgente'' significa che il nastro viene riavvolto quando il file di periferica viene chiusa; ``non-riavvolgente'' sta ad indicare che il nastro non è automaticamente riavvolto quando la periferica viene chiusa (ma, ovviamente, è possibile utilizzare i comandi bsf ed fsf di movimento del nastro per posizionare la testina in qualsiasi posizione si desideri).

<risposta di Claus Heine>

11.26 Qual'è la differenza fra ciò che mt considera un record e ciò che considera un file?

Un record è il quantitativo minimo di byte che verranno accettati dal nastro in una singola operazione di lettura/scrittura (tranne che nel modo ``variable block size mode [modalità dimensione blocco variabile]'', per la quale dovrebbe rappresentare il quantitativo di dati effettivamente scritti in una singola operazione di scrittura).

Per zftape ogni accesso per lettura o scrittura deve essere un multiplo di una dimensione di blocco fissa (fissa, ma regolabile con MTSETBLK). La dimensione di blocco è un ``tape record [record del nastro]'' (come viene chiamata nella pagina di manuale di GNU mt) ed assume un valore di 10kB per zftape.

Un ``file'' (nella terminologia delle pagine di manuale di mt) è un termine ben definito. Sta ad indicare un'area del nastro fra due marcatori di file. Questo non è un file come lo è quello di un filesystem, nel senso che possiede un nome, delle modalità di accesso, può essere spostato o copiato con cp, mv, rm, etc.

Al contrario, è semplicemente l'area del nastro che è stata registrata in una sessione di backup, la sua fine è marcata con un marcatore di file del nastro e il suo inizio è delimitato da un BOT o dal marcatore del ``file'' precedente. Questi ``file'' di nastro sono oggetti che possono essere saltati con i comandi mt bsf ed mt fsf.

<risposta di Claus Heine>

11.27 Riutilizzare nastri con zftape senza riformattare il nastro.

Proviamo a rispondere alle seguenti domande:

Se si desidera ``cancellare'' un'intera cartuccia, digitare semplicemente: 

mt -f /dev/qft0 erase

Questo cancellerà la tavola dei volumi (cioè i marcatori di file).

Con le versioni di ftape o zftape antecedenti la 3.x era possibile sovrascrivere volumi già presenti sulla cartuccia. Ho rimosso questa caratteristica in quanto mi è stato riferito che ha già causato la perdita di dati con alcuni programmi di backup.

Se, invece, si necessita di rimuovere alcuni volumi dal nastro, allora si deve utilizzare il programma 

vtblc

che viene distribuito con il pacchetto ftape-tools scaricabile dallo stesso sito del pacchetto dei driver del kernel di ftape. Si prega di fare riferimento alla documentazione contenuta nel pacchetto ftape-tools per maggiori informazioni.

Se si desidera semplicemente riutilizzare vecchi nastri, allora è sufficiente impartire un 

mt rewind

Se il nastro si trova al BOT (Begin Of Tape [inizio del nastro]), allora ogni accesso in scrittura al nastro cancellerà implicitamente tutti i marcatori di file e sovrascriverà i dati già presenti sul nastro.

<risposta di Claus Heine>

11.28 Questo script permette di ottenere un semplice indice di un pacchetto zftape utilizzando lo ioctl TIOCVOLINFO.

Qui di seguito viene riportato un piccolo script in perl/bash che list il contenuto di una cartuccia utilizzando lo specifico ioctl ``volinfo'' di zftape. Spero che permetta di capire come trattare questo tipo di esigenza.

Ciò che fondamentalmente fa è:

  1. riavvolgere la cartuccia;
  2. impartire il comando volinfo 
       claus@thales:~$ mt volinfo
   file number          = 1
   block size           = 10240
   physical space used  =  522.0 kilobytes
   real size of volume  =  520.0 kilobytes
    analizzandone il contenuto e posizionando i valori in varibili appropriate;
  3. saltare al volume successivo con mt fsf;
  4. uscire se questo produce un errore (EOD), oppure saltare al secondo passo.

Lo script in Perl 

#!/usr/bin/perl
#
#     Copyright (C) 1997 Claus-Justus Heine
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING.  If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
#
#   This script implements a simple contents listing for the zftape
#   package using the MTIOCVOLINFO ioctl.
#

$version = <<EOT;
listtape-1.0 -- a perl script to list the contents of a floppy tape cartridge
under Linux using the zftape driver

RCS \$Revision: 1.16 $
RCS \$Date: 1999/04/05 20:18:16 $
EOT

$tapedev = "/dev/tape";
$usage"= <<EOT;
Usage: listtape [options ...]

Mandatory or optional arguments to long options are mandatory or optional
for short options too.

-f, --file=FILE       Tape device to use. Default is  "/dev/tape".
-h, --help            Print this help.
-?                    Same as '-h'.
--usage           Same as '-h'.
-V, --version         Print version information.

Author: Claus-Justus Heine <claus\@momo.math.rwth-aachen.de>
EOT

while ($ARGV[0] =~ /^-/) {
$_ = shift; 
if (/--file/) {$_ = shift; $tapedev = $_; next;} 
if (/-f/) {$_ = shift; $tapedev = $_; next;} 
if (/--help/) { print $usage; exit 0; }
if (/-h/) { print $usage; exit 0; }
if (/--usage/) { print $usage; exit 0; }
if (/-\?/) { print $usage; exit 0; }
if (/--version/) { print $version; exit 0; }
if (/-V/) { print $version; exit 0; }
die $usage;
}

&open_tape($tapedev, "status");
while(<FTMT>)
{
$online = 1 if (/.*online.*/);
}

if (! $online) { die "No cartridge present.\n"; }

&mtop($tapedev, "rewind");

printf "%11s%12s%20s%20s\n",
"file number", "block size", "volume size", "tape space";

while (1)
{
&open_tape($tapedev, "volinfo");
while (<FTMT>) {
if (/^file number\s*=\s*([0-9]*)$/) { $filenumber = $1; }
if (/^block size\s*=\s*([0-9]*)$/) { $blocksize = $1; }
if (/^physical space used\s*=\s*([[0-9]*.*)/) { $rawsize = $1; }
if (/^real size of volume\s*=\s*([[0-9]*.*)/) { $size = $1; }
}
close(FTMT);
if (&mtop($tapedev, "fsf 1") != 0) {
&mtop($tapedev,"rewind");
print "\nRemaining space: $rawsize\n";
print "Tape block size: $blocksize\n";
exit 0;
}           
printf "%6d          %5d  %20s%20s\n",
    $filenumber, $blocksize, $size, $rawsize;
}

sub mtop
{
local ($tape, $operation) = @_;
local ($exitval);
system "ftmt -f $tape $operation > /dev/null 2>&1";
}

sub open_tape
{
local ($tape, $operation) = @_;
local ($command);

$command = "ftmt -f " . $tape . " " . $operation . " |";
open(FTMT, $command) || die "Couldn't open $command -- $!\n";
}

Lo script in Bash 

#! /bin/bash
#
#     Copyright (C) 1997 Claus-Justus Heine
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING.  If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
#
#   This script implements a simple contents listing for the zftape
#   package using the MTIOCVOLINFO ioctl.
#

#
# insert better option parsing here
#
TAPEDEV=${1-/dev/tape}

if ! echo $TAPEDEV | grep "/dev/n"
then
TAPEDEV=/dev/n$(basename $TAPEDEV)
fi

if ! [ -c $TAPEDEV ]
then
echo $TAPEDEV is not a character device!  1>&2
exit 1
fi

if ! mt -f $TAPEDEV rewind
then
echo Could not rewind $TAPEDEV - no cartridge present?  1>&2
exit 1
fi

echo -e "\nContents of $TAPEDEV:\n"

printf "%11s%12s%20s%20s\n" "file number" "block size" "volume size" "tape space"

trap "rm -f /tmp/$0.$$" exit

while true
do
if ! foo=$(mt -f $TAPEDEV volinfo |cut -f 2 -d =)
then
echo $TAPEDEV doesn\'t seem to be a floppy tape device 1>&2
exit 1
fi
#
# "echo foo | read foo" will not work as the "read foo" is executed in
# another shell.
#
echo $foo > /tmp/$0.$$
read file blksz used usedunit size sizeunit < /tmp/$0.$$
if ! mt -f $TAPEDEV fsf 1 > /dev/null 2>&1
then
echo -e "\nRemaining space: $used $usedunit"
echo -e "Tape block size: $blksz"
if ! mt -f $TAPEDEV rewind
then
    echo Rewind of $TAPEDEV failed 1>&2
    exit 1
fi
exit 0
fi
printf "%6d          %5d  %20s%20s\n"\
$file $blksz "$size $sizeunit" "$used $usedunit"
done

<risposta di Claus Heine>

Avanti Indietro Indice

Hosting by: hurra.com
Generated: 2007-01-26 17:56:16