È 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).
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>
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.
<risposta di Tim Jones e Claus Heine>
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.
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.
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>
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>
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:
afio:
mt -f /dev/qft0 setblk 5120
mt -f /dev/qft0 setblk 0
KBackup, questo è il solo modo per farlo lavorare assieme ad
Ftape (perlomeno dovrebbe funzionare, ma non so con esattezza se
lo fa).
tar). Per afio è possibile utilizzare il
seguente comando:
afio -b 10k ...
È 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>
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>
/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
$ 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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:
cvanzamento veloce al prossimo marcatore di file verso l'EOT (End Of Tape [fine del nastro]),
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>
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>
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>
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>
/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>
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>
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>
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 è:
volinfo
claus@thales:~$ mt volinfo
file number = 1
block size = 10240
physical space used = 522.0 kilobytes
real size of volume = 520.0 kilobytes
mt fsf;
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.3 $
RCS \$Date: 2000/11/07 22:51:52 $
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 <heine\@instmath.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>