pkg://Ftape-HOWTO.html.tgz:50081/Ftape-HOWTO-11.html
downloads
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>The Linux Ftape-HOWTO: FAQ: domande relative all'«utilizzo di Ftape»!</TITLE>
<LINK HREF="Ftape-HOWTO-12.html" REL=next>
<LINK HREF="Ftape-HOWTO-10.html" REL=previous>
<LINK HREF="Ftape-HOWTO.html#toc11" REL=contents>
</HEAD>
<BODY>
<A HREF="Ftape-HOWTO-12.html">Avanti</A>
<A HREF="Ftape-HOWTO-10.html">Indietro</A>
<A HREF="Ftape-HOWTO.html#toc11">Indice</A>
<HR>
<H2><A NAME="s11">11. FAQ: domande relative all'«utilizzo di Ftape»!</A></H2>
<P>
<P>
<H2><A NAME="ss11.1">11.1 Quanto va veloce Ftape?</A>
</H2>
<P>
<P>È possibile ottenere velocità di backup e ripristino abbastanza
rispettabili con <EM>Ftape</EM>: 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 <EM>Ftape</EM> 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).
<P>
<P>
<H2><A NAME="ss11.2">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?</A>
</H2>
<P>
<P>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.
<P><dall'Ftape-HOWTO>
<P>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
<P>
<BLOCKQUOTE><CODE>
<PRE>
ftmt -f /dev/zqft0 reten
</PRE>
</CODE></BLOCKQUOTE>
<P>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.
<P><risposta di Tim Jones>
<P>Se si utilizza <CODE>afio</CODE> come strumento di backup, è possibile fargli
scrivere un gran numero di buffer in un colpo solo utilizzando il flag
<CODE>-c</CODE>. 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:
<P>
<BLOCKQUOTE><CODE>
<PRE>
find /usr/local -xdev -print | afio -o -v -f -b 10240 -c 800 /dev/qft0
</PRE>
</CODE></BLOCKQUOTE>
<P>Nel mio caso sto scrivendo 800x1024 byte per ogni scrittura sul
nastro, cioè cira 8MB.
<P>Non ho fatto molte esperienze con queste impostazioni, cosí qualcuno
potrebbe volerne cercare di migliori.
<P>Probabilemente altre utility di backup possono essere modificate per
utilizzare una tecnica simile.
<P><risposta di Michael Hamilton>
<P>Il <CODE>tar</CODE> di GNU non utilizza i buffer in questo modo. Il programma
di backup commerciale <CODE>bru</CODE> è in grado di trattare buffer multipli
utilizzando memoria condivisa; questo funziona solo quando si sta
scrivendo archivi compressi con <CODE>bru</CODE> (indipendentemente dal fatto
che si stia utilizzando la compressione di <EM>Ftape</EM>).
<P>Un altro modo per sopperire al problema potrebbe essere quello di
utilizzare piú buffer DMA nel <EM>driver Ftape del kernel</EM>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
mt -f /dev/qft0 setdrvbuffer $((6*32786))
</PRE>
</CODE></BLOCKQUOTE>
<P>$((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 <EM>Ftape</EM> 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.
<P><risposta di Claus Heine>
<P>
<H2><A NAME="ss11.3">11.3 Devo far ripartire il mondo DOS per formattare i nastri?</A>
</H2>
<P>
<P>No, se si sta usando l'ultima versione dei <EM>driver di Ftape</EM>
disponibile all'
<A HREF="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/">home-page di Ftape</A>.
<P>Per formattare un nastro QIC-80, TR-1, TR-3, QICWide 3010 o 3020,
procurarsi l'ultima versione di <CODE>ftape</CODE> e l'ultima
versione del pacchetto <CODE>ftape-tools</CODE> (dallo stesso sito)
e leggere la documentazione dell'utility <CODE>ftformat</CODE>
inclusa nel pacchetto <CODE>ftape-tools</CODE>.
<P>
<H4>Comment</H4>
Non provare a formattare nastri Ditto 2GB.
<H4>Comment</H4>
Non provare a formattare nastri Ditto Max o Max Pro.
<P><risposta di Tim Jones e Claus Heine>
<P>
<P>
<H2><A NAME="ss11.4">11.4 È possibile formattare nastri Ditto 2GB con ftape?</A>
</H2>
<P>
<P>Non è possibile formattare nastri <CODE>Ditto 2GB</CODE> con unità a nastro
<CODE>Ditto 2GB</CODE>, cosí come non è assolutamente possibile riformattare
nastri <CODE>Ditto 2GB</CODE> in modo tale da poter essere utilizzati ancora
da unità a nastro <CODE>Ditto 2GB</CODE>.
<P>Questa è una limitazione hardware dell'unità a nastro <CODE>Ditto 2GB</CODE>.
Non c'è possibilità di aiuto a livello software, cioè non è una
mancanza di <CODE>ftape</CODE>.
<P>
<P>
<H2><A NAME="ss11.5">11.5 È possibile formattare nastri Ditto Max o Max Pro con ftape?</A>
</H2>
<P>
<P>No, il <CODE>Ditto Max</CODE> non può formattare nastri.
<P>Questa è una limitazione hardware dell'unità a nastro <CODE>Ditto 2GB</CODE>.
Non c'è possibilità di aiuto a livello software, cioè non è una
mancanza di <CODE>ftape</CODE>.
<P>
<P>
<H2><A NAME="ss11.6">11.6 Ftape rileva piú settori danneggiati con nastri QIC-3020 di quanto non faccia DOS.</A>
</H2>
<P>
<P>Se si presta attenzione alla differenza, si noterà che <EM>Ftape</EM>
rileva sempre 2784 settori in piú di DOS.
<P>Il numero che <EM>Ftape</EM> riporta è corretto (ovviamente <CODE>:-)</CODE>.
Tutti i nastri QIC-3020 correttamente formattati hanno 2784 settori in
posizioni predefinite che sono marcati nella mappa dei settori
danneggiati. Quotando dalle specifiche:
<P>
<BLOCKQUOTE>
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.??
</BLOCKQUOTE>
<P>Questo fornisce 12 tracce * 2 * 4 segmenti * 29 settori = 2784
settori.
<P>Cosí <EM>Ftape</EM> 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 <EM>Ftape</EM>, 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à.
<P>I nastri QIC-3010 sono simili ai QIC-3020 al riguardo.
<P><dall'Ftape-HOWTO>
<P>
<P>
<H2><A NAME="ss11.7">11.7 Non ci sono problemi se non sento il nastro muoversi quando impartisco un comando <CODE>fsf</CODE> o <CODE>bsf</CODE> con <CODE>mt</CODE>?</A>
</H2>
<P>
<P>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.
<P><dall'Ftape-HOWTO>
<P>
<P>
<H2><A NAME="ss11.8">11.8 Perché il mio programma di backup <I>XYZ</I> si lamenta di errori di tipo ``Invalid argument'' [argomento non valido]?</A>
</H2>
<P>
<P><CODE>zftape</CODE> 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:
<UL>
<LI>impostare la dimensione dei blocchi di <EM>Ftape</EM> alla
dimensione dei blocchi utilizzati dal programma di backup. L'esempio
sottostante è applicabile ad <CODE>afio</CODE>:
<BLOCKQUOTE><CODE>
<PRE>
mt -f /dev/qft0 setblk 5120
</PRE>
</CODE></BLOCKQUOTE>
</LI>
<LI>se non si vuole utilizzare la compressione di <EM>Ftape</EM>, è
anche possibili usare:
<BLOCKQUOTE><CODE>
<PRE>
mt -f /dev/qft0 setblk 0
</PRE>
</CODE></BLOCKQUOTE>
per attivare la modalità di dimensione variabile dei blocchi di
<EM>Ftape</EM> ed essere in grado di scrivere i dati sul nastro in
porzioni arbitrarie (<B>ma</B> la compressione interna non funziona con
questa impostazione). Quando si avesse l'intenzione di utilizzare
<CODE>KBackup</CODE>, questo è il solo modo per farlo lavorare assieme ad
<EM>Ftape</EM> (perlomeno dovrebbe funzionare, ma non so con esattezza se
lo fa).
</LI>
<LI>informare il proprio programma di backup circa la dimensione di
default di 10kB dei blocchi di <EM>Ftape</EM> (che è anche il valore
tipico per GNU <CODE>tar</CODE>). Per <CODE>afio</CODE> è possibile utilizzare il
seguente comando:
<BLOCKQUOTE><CODE>
<PRE>
afio -b 10k ...
</PRE>
</CODE></BLOCKQUOTE>
</LI>
</UL>
<P>È opportuno leggersi la sezione ``Tape blocks'' del manuale
(utilizzare l'indice analitico per andare direttamente alla sezione
relativa).
<P>Quando si utilizza la compressione interna di GNU <CODE>tar</CODE> con
versione di GNU <CODE>tar</CODE> antecedente la tar-1.12, è necessario
lanciare <CODE>tar</CODE> con l'opzione <CODE>--block-compress</CODE> impostata su
<CODE>re-block</CODE>. In caso contrario <CODE>tar</CODE> comprimerà i dati che
legge e li scriverà in porzioni arbitrarie sul nastro.
<P>Eesempio:
<BLOCKQUOTE><CODE>
<PRE>
tar -czvf /dev/qft0 --block-compress /etc
</PRE>
</CODE></BLOCKQUOTE>
<P><B>Attenzione:</B> non si dovrebbe utilizzare la compressione interna di
<CODE>tar</CODE> 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.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.9">11.9 Errori I/O e FDC: alcune spiegazioni.</A>
</H2>
<P>
<P>Se si ottengono i seguenti messaggi, questo è ciò che fa per te!
<UL>
<LI>fdc-io.c (ft_handle_perpend) - Your FDC does not support
QIC-3020 [l'FDC non supporta il QIC-3020].
</LI>
<LI>Cannot write to /dev/qft0: I/O error [non posso scrivere su
/dev/qft0: errore di I/O].</LI>
</UL>
<P>La spiegazione:
<P>``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).
<P>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).
<P>È 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.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.10">11.10 Perché ottengo errori del tipo «<CODE>/dev/qft0: No such device</CODE>» [/dev/qft0: nessun device come questo]?</A>
</H2>
<P>
<P>Supponiamo che il problema sia il seguente. Il modulo <EM>Ftape</EM> è
caricato correttamente nel kernel:
<P>
<BLOCKQUOTE><CODE>
<PRE>
/usr/src/ftape-3.03b-970603# lsmod
Module Pages Used by
ftape 22 0
</PRE>
</CODE></BLOCKQUOTE>
ma accade che:
<BLOCKQUOTE><CODE>
<PRE>
$ ftmt -f /dev/qft0 status
ftmt: /dev/qft0: No such device
</PRE>
</CODE></BLOCKQUOTE>
<P>La soluzione: è necessario anche caricare il modulo <EM>zftape.o</EM>.
Con Ftape-3.* il modulo <EM>ftape.o</EM> non implementa l'interfaccia VFS.
Questo è fatto da <EM>zftape.o</EM>.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.11">11.11 Ottengo un ``device busy'' [periferica occupata] quando eseguo backup multipli su di un nastro utilizzando alcuni script.</A>
</H2>
<P>
<P>I messaggi di ``periferica occupata'' possono verificarsi mentre le
<EM>file di periferica di Ftape</EM> 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
<CODE>bru</CODE>, o altri programmi, abbiano eseguito un fork di un figlio che
ritarda a morire?
<P>Sí, questo riproduce il problema:
<BLOCKQUOTE><CODE>
<PRE>
tar -cvvzf /dev/nqft0 --block-compress ; mt rewind
</PRE>
</CODE></BLOCKQUOTE>
<P>È possibile omettere <CODE>--block-compress</CODE> se si sta utilizzando
un versione di GNU <CODE>tar</CODE> piú recente.
<P>Comunque questo non è un baco di <EM>Ftape</EM>. Sembra che il processo
<CODE>tar</CODE> genitore esca prima che suo figlio abbia chiuso il device del
nastro. So comunque, per aver studiato il codice di <CODE>tar</CODE> alcuni
anni fa, che <CODE>tar</CODE> attende correttamente che il proprio genitore
muoia.
<P>In ogni caso, il messaggio di occupato significa semplicemente che la
variabile ``busy'' [occupato] è ancora mantenuta ad un valore logico 1
(<CODE>zftape/zftape-init.c</CODE>), e questo significa semplicemente che
c'è ancora un processo in giro che tiene il device del nastro aperto.
<P>Penso di aver capito il motivo (solo nel caso di <CODE>tar</CODE> in quanto di
questo ho il codice sorgente).
<P>Se si utilizza <CODE>tar</CODE> con la compressione abilitata, allora viene
eseguito un fork di un figlio che diventerà il compressore tramite
l'esecuzione di <CODE>gzip</CODE> o qualcos'altro. Prima della chiamata a
execlp(), il figlio eseguirà un fork di un nipote di suo padre
<CODE>tar</CODE>. Questo nipote eseguirà l'effettvo lavoro di I/O sul nastro.
<P>
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
<P>Ora, il genitore <CODE>tar</CODE> aspetta che suo figlio muoia. <CODE>gzip</CODE>
sicuramente non aspetta il nipote in quanto <CODE>gzip</CODE> è il risultato
di un execlp().
<P>Ciò che non so è se il nipote dovrebbe essere implicitamente aspettato
dal genitore <CODE>tar</CODE> o se la funzione wait() aspetta anche i nipoti.
<P>Comunque questo sembra essere il problema: il genitore <CODE>tar</CODE> è
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 <EM>Ftape</EM>, mentre lo è nei programmi di backup, nel
kernel o forse nel codice d'uscita delle libc.
<P>Non so se le considerazione fatte in precedenza si possono essere
applicate anche a <CODE>bru</CODE>. Se non ci sono nipoti e il processo padre
attende in maniera corretta suo figlio, allora non ci dovrebbero
essere problemi.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.12">11.12 Come faccio a... con <CODE>tar</CODE>?</A>
</H2>
<P>
<P>Queste sono propriamente domande per <CODE>tar</CODE>: si prega di leggersi la
pagina <CODE>man</CODE> e la pagina <CODE>info</CODE> realtive. Se non sono
installate sul sistema, provare con
<P>
<BLOCKQUOTE><CODE>
<PRE>
tar --help 2>&1 | less
</PRE>
</CODE></BLOCKQUOTE>
<P>Se la propria versione di <CODE>tar</CODE> è la v1.11.1 o precedente, si
consideri l'opportunità di aggiornarla alla v1.11.8. Questa versione
può chiamare GNU <CODE>zip</CODE> direttamente (cioè supporta l'opzione
<CODE>-z</CODE>) e possiede un elaborato help incluso. Inoltre tutto può
essere compilato in ambiente Linux.
<P><dall'Ftape-HOWTO>
<P>
<P>
<H2><A NAME="ss11.13">11.13 Che dimensione per i blocchi devo utilizzare con <CODE>tar</CODE>?</A>
</H2>
<P>
<P>Se si fa uso della compressione (ed anche piú in generale), può
tornare a proprio favore specificare a <CODE>tar</CODE> che deve
spezzettare l'uscita in blocchi grossi. Poiché <EM>Ftape</EM>
taglia i dati in blocchi da 29kB, un ``<CODE>-b58</CODE>'' dovrebbe
essere ottimo.
<P>«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í <EM>Ftape</EM> prende
29kB di dati, aggiunge 3kB di parità ECC e scrive 32kB sul nastro alla
volta. Per questa ragione <EM>Ftape</EM> scriverà e leggerà sempre
blocchi da 32kB per essere in grado di rilevare (e correggere)
eventuali errori.
<P>Se si possiede una spiccata curiosità e si vuole conoscere di piú, è
possibile dare un'occhiata ai file <CODE>ecc.c</CODE> ed <CODE>ecc.h</CODE> per una
spiegazione del codice e un riferimento a testi sui codici
Reed-Solomon.
<P><dall'Ftape-HOWTO>
<P>
<P>
<H2><A NAME="ss11.14">11.14 Dove posso trovare i binari, i sorgenti e le pagine <CODE>man</CODE> di <CODE>tar</CODE>, <CODE>mt</CODE>, <CODE>cpio</CODE> e <CODE>dd</CODE>?</A>
</H2>
<P>
<P>Tutti questo strumenti sono stati sviluppati dal progetto GNU ed i
sorgenti (cosí come le pagine <CODE>man</CODE>) possono essere prelevate da
praticamente ogni sito ftp nel mondo (inclusi <CODE>ftp.funet.fi</CODE>,
<CODE>tsx-11.mit.edu</CODE>, e <CODE>sunsite.unc.edu</CODE>). In ogni caso possono
essere prelevati dal sito ufficiale GNU: <CODE>prep.ai.mit.edu
[18.71.0.38]:/pub/gnu</CODE>. Le ultime versioni (ad oggi 12 settembre
1996) sono:
<P>
<BLOCKQUOTE><CODE>
<PRE>
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)
</PRE>
</CODE></BLOCKQUOTE>
<P>Tutto quanto può essere compilato in ambiente Linux successivo alla
versione v1.0.4, <CODE>libc</CODE> v4.5.19 e <CODE>gcc</CODE> v2.5.8.
<P><dall'Ftape-HOWTO>
<P>
<P>
<H2><A NAME="ss11.15">11.15 Se utilizzo la compressione dell'unità a nastro, è sbagliato sfruttare anche la compressione di <CODE>zftape</CODE>. O sarebbe meglio non utilizzare la compressione dell'unità e lasciare che faccia tutto <CODE>zftape</CODE>?</A>
</H2>
<P>
<P>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 <EM>ftape</EM>), ma non ha senso. Non si guadagna un
maggior compressione, ma solo cicli di CPU sprecati.
<P>La compressione dell'unità dovrebbe essere abbastanza sicura, in
quanto l'unità comprime singoli file, a differenza di <CODE>tar
-czf...</CODE>, 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.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.16">11.16 Com'è la compressione di <CODE>zftape</CODE> a confronto di quella, diciamo, di <CODE>gzip -9</CODE>?</A>
</H2>
<P>
<P><CODE>gzip -9</CODE> è migliore (cioè si può ottenere una maggiore
compressione). La compressione di <EM>zftape</EM> è paragonabile al
programma Un*x <CODE>compress</CODE>, ma dovrebbe essere piú veloce, e lo è
rispetto a <CODE>gzip</CODE>.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.17">11.17 Non utilizzo la compressione, ma sento che l'interfaccia <CODE>zftape</CODE> se ne sta andando. Cosa posso fare?</A>
</H2>
<P>
<P>Si utilizzi l'<EM>interfaccia zftape</EM>, senza caricare il modulo
<EM>zft-compressor</EM>. Il device allora diventa <CODE>/dev/qft0</CODE>.
<P><risposta di Tim Jones>
<P>
<P>
<H2><A NAME="ss11.18">11.18 Ftape dice «<CODE>This tape has no 'Linux raw format'</CODE>» [questo nastro non è nel ``formato elementare Linux''].</A>
</H2>
<P>
<P>Si ottiene questa lamentela se non si è <EM>cancellato</EM> il proprio
nastro appena formattato. Questo accade perché <EM>Ftape</EM> 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:
<P>
<PRE>
mt -f /dev/nftape erase
</PRE>
<P><dall'Ftape-HOWTO>
<P>
<P>
<H2><A NAME="ss11.19">11.19 Posso scambiare nastri con qualcuno che utilizza il DOS?</A>
</H2>
<P>
<P>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.
<P><dall'Ftape-HOWTO>
<P>
<P>
<H2><A NAME="ss11.20">11.20 Come funziona <CODE>mt eom</CODE> quando si comincia a sovrascrivere un nastro dalla metà?</A>
</H2>
<P>
<P>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.
<P>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.
<P><dall'Ftape-HOWTO>
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.21">11.21 Quando eseguivo dei backup prima di utilizzare <CODE>taper</CODE>, sotto ftape 2.0.29 la mia unità non supportava l'fsf, mentre sotto il nuovo <CODE>zftape</CODE> lo supporta. Perché dovrebbe e cos'è esattamente l'fsf?</A>
</H2>
<P>
<P>Probabilmente non funzionava prima perché non si era utilizzato un
<P>
<BLOCKQUOTE><CODE>
<PRE>
mt -f /dev/rft0 erase
</PRE>
</CODE></BLOCKQUOTE>
<P>prima di scrivere i dati sulla cartuccia. Questo <B>non è piú</B>
necessario.
<P>Ma ``<CODE>mt fsf</CODE>'', cosa significa? Le unità a nastro non registrano
i file in modo che si possa utilizzare un
<P>
<PRE>
cp qualche_file /dev/la_mia_unità
</PRE>
<P>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.
<P>Poiché queste è abbastanza scomodo, qualcuno ha inventato qualcosa che
è conosciuto con il nome di <I>file mark</I> o <I>eof mark</I> (<I>eof</I> è
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).
<P>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
<P>
<BLOCKQUOTE><CODE>
<PRE>
tar -cf /dev/nqft0 /bin
tar -cf /dev/nqft0 /etc
mt -f /dev/nqft0 rewind
</PRE>
</CODE></BLOCKQUOTE>
<P>si otterrebbe un backup di tutti i file sotto <CODE>/bin</CODE> ed
<CODE>/etc</CODE>. Quando il primo <CODE>tar</CODE> 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 <CODE>tar</CODE>, 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.
<P>I comandi che fanno questo sono:
<DL>
<DT><B>mt fsf</B><DD><P>cvanzamento veloce al prossimo marcatore di file verso
l'EOT (End Of Tape [fine del nastro]),
<P>
<DT><B>mt bsf</B><DD><P>avanzamento veloce al prossimo marcatore di file verso il
BOT (Begin Of Tape [inizio del nastro]).
</DL>
<P>Cosí, per estrarre il secondo archivio nell'esempio precedente, non è
necessario rileggere il primo archivio, ma procedere come segue:
<P>
<BLOCKQUOTE><CODE>
<PRE>
mt -f /dev/nqft0 rewind
mt -f /dev/nqft0 fsf
tar -xvf /dev/nqft0
</PRE>
</CODE></BLOCKQUOTE>
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.22">11.22 Qual'è esattamente la differenza fra <CODE>ftape</CODE> e <CODE>zftape</CODE>?</A>
</H2>
<P>
<P>Quando <EM>Ftape</EM> era ancora giovane, c'erano due versioni dei driver
per unità a nastro, una delle quali venne chiamata <EM>zftape</EM> 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 <CODE>ioctl</CODE>
e l'uso dei marcatori di file forniti da <EM>zftape</EM> erano
notevolmente superiore e con meno bachi. Inoltre <EM>zftape</EM> permette
di utilizzare cartucce a nastro per floppy con differenti sistemi
operativi. Beh, non è possibile scambiare dati, ma <EM>ftape</EM> non
sovrascriverà i volumi creati con il proprio programma Windoze e
viceversa.
<P>Oggi giorno <EM>Ftape</EM> è il nome dell'intero pacchetto di driver per
unità a nastro via controller floppy, <B>ed</B> <CODE>ftape.o</CODE> è il nome
del file del modulo kernel che implementa il supporto hardware a basso
livello. <CODE>zftape</CODE> ha cessato di esistere come un pacchetto
separato, mentre la nuova versione di <EM>Ftape</EM> (da ftape-3.00)
contiene un modulo <CODE>zftape.o</CODE> che si appoggia ad <CODE>ftape.o</CODE> (cioè
diventa necessario caricare <B>entrambi</B> 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
<CODE>zftape</CODE>.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.23">11.23 Qual'è la differenza fra una periferica riavvolgente ed una non-riavvolgente?</A>
</H2>
<P>
<P>Beh, i file delle periferiche a nastro riavvolgenti riavvolgono il
nastro al BOT (Begin Of Tape [inizio del nastro]), cioè
<P>
<BLOCKQUOTE><CODE>
<PRE>
tar -cvf /dev/qft0 /bin
</PRE>
</CODE></BLOCKQUOTE>
<P>riavvolgerà la cartuccia quando il lavoro di <CODE>tar</CODE> è terminato.
Invece
<P>
<BLOCKQUOTE><CODE>
<PRE>
tar -cvf /dev/nqft0 /bin
</PRE>
</CODE></BLOCKQUOTE>
<P><B>non</B> riavvolgerà la cartuccia e lascierà la testina di
lettura/scrittura nella possizione corrente.
<P>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.
<P>Le periferiche non-riavvolgenti <B>devono</B> essere utilizzate quando
si invia un qualsiasi comando di movimento all'unità a nastro, come
<P>
<BLOCKQUOTE><CODE>
<PRE>
mt -f /dev/nqft0 fsf
</PRE>
</CODE></BLOCKQUOTE>
<P>perché, quando il processo <CODE>mt</CODE> termina, l'unità a nastro viene
chiusa e ciò comporta un riavvolgimento della cartuccia con le
periferiche riavvolgenti.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.24">11.24 C'è qualcuno che potrebbe dirmi come utilizzare <CODE>mt</CODE> per riavvolgere la mia unità TR-3 dopo aver registrato un archivio con <CODE>zftape</CODE>, cosí da poterlo verificare?</A>
</H2>
<P>
<P>Beh, dipende. Se il nastro è ancora posizionato all'interno del
volume appena scritto, un ``<CODE>mt bsf 1</CODE>'' (o equivalentemente
``<CODE>mt bsf</CODE>'') farà ritornare il nastro proprio all'inizio di quel
volume (questo è il modo in cui <CODE>tar --verify</CODE> lavora). Se il
nastro è già posizionato <B>dopo</B> il marcatore di file che indica la
fine dell'ultimo volume scritto, allora è neccessario impartire un
``<CODE>mt bsf 2</CODE>''.
<P>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 <CODE>mt bsf 2</CODE> posizionerà il nastro esattamente all'inizio del
precedente volume.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.25">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 <CODE>/dev/zqft0</CODE> ed il nastro è stato subito riavvolto.</A>
</H2>
<P>
<P>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 <CODE>bsf</CODE> ed <CODE>fsf</CODE> di
movimento del nastro per posizionare la testina in qualsiasi posizione
si desideri).
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.26">11.26 Qual'è la differenza fra ciò che <CODE>mt</CODE> considera un record e ciò che considera un file?</A>
</H2>
<P>
<P>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).
<P>Per <CODE>zftape</CODE> ogni accesso per lettura o scrittura deve essere un
multiplo di una dimensione di blocco fissa (fissa, ma regolabile con
<CODE>MTSETBLK</CODE>). La dimensione di blocco è un ``tape record [record
del nastro]'' (come viene chiamata nella pagina di manuale di GNU
<CODE>mt</CODE>) ed assume un valore di 10kB per <CODE>zftape</CODE>.
<P>Un ``file'' (nella terminologia delle pagine di manuale di <CODE>mt</CODE>) è
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 <CODE>cp</CODE>, <CODE>mv</CODE>, <CODE>rm</CODE>, etc.
<P>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 <CODE>mt bsf</CODE> ed <CODE>mt fsf</CODE>.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.27">11.27 Riutilizzare nastri con <CODE>zftape</CODE> senza riformattare il nastro.</A>
</H2>
<P>
<P>Proviamo a rispondere alle seguenti domande:
<UL>
<LI>C'è un buon metodo per cancellare o rimuovere dati, o almeno
volumi dal nastro, senza riformattarlo?
</LI>
<LI>È possibile sovrascrivere l'ultimo volume di un nastro senza
fare un disastro?
</LI>
<LI>È possibile sovrascrivere gli ultimi volumi senza fare danni?
</LI>
<LI>È possibile cancellare l'ultimo volume?</LI>
</UL>
<P>Se si desidera ``cancellare'' un'intera cartuccia, digitare
semplicemente:
<P>
<BLOCKQUOTE><CODE>
<PRE>
mt -f /dev/qft0 erase
</PRE>
</CODE></BLOCKQUOTE>
<P>Questo cancellerà la tavola dei volumi (cioè i marcatori di file).
<P>Con le versioni di <CODE>ftape</CODE> o <CODE>zftape</CODE> antecedenti la 3.<I>x</I>
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.
<P>Se, invece, si necessita di rimuovere alcuni volumi dal nastro, allora
si deve utilizzare il programma
<P>
<BLOCKQUOTE><CODE>
<PRE>
vtblc
</PRE>
</CODE></BLOCKQUOTE>
<P>che viene distribuito con il pacchetto <CODE>ftape-tools</CODE> scaricabile
dallo stesso sito del pacchetto dei driver del kernel di <CODE>ftape</CODE>.
Si prega di fare riferimento alla documentazione contenuta nel
pacchetto <CODE>ftape-tools</CODE> per maggiori informazioni.
<P>Se si desidera semplicemente riutilizzare vecchi nastri, allora è
sufficiente impartire un
<P>
<BLOCKQUOTE><CODE>
<PRE>
mt rewind
</PRE>
</CODE></BLOCKQUOTE>
<P>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.
<P><risposta di Claus Heine>
<P>
<P>
<H2><A NAME="ss11.28">11.28 Questo script permette di ottenere un semplice indice di un pacchetto <CODE>zftape</CODE> utilizzando lo ioctl <CODE>TIOCVOLINFO</CODE>.</A>
</H2>
<P>
<P>Qui di seguito viene riportato un piccolo script in perl/bash che list
il contenuto di una cartuccia utilizzando lo specifico ioctl
``volinfo'' di <CODE>zftape</CODE>. Spero che permetta di capire come
trattare questo tipo di esigenza.
<P>Ciò che fondamentalmente fa è:
<OL>
<LI>riavvolgere la cartuccia;
</LI>
<LI>impartire il comando <CODE>volinfo</CODE>
<BLOCKQUOTE><CODE>
<PRE>
claus@thales:~$ mt volinfo
file number = 1
block size = 10240
physical space used = 522.0 kilobytes
real size of volume = 520.0 kilobytes
</PRE>
</CODE></BLOCKQUOTE>
analizzandone il contenuto e posizionando i valori in varibili
appropriate;
</LI>
<LI>saltare al volume successivo con <CODE>mt fsf</CODE>;
</LI>
<LI>uscire se questo produce un errore (EOD), oppure saltare al
secondo passo.</LI>
</OL>
<P><B>Lo script in Perl</B>
<HR>
<PRE>
#!/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";
}
</PRE>
<HR>
<P>
<P><B>Lo script in Bash</B>
<HR>
<PRE>
#! /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
</PRE>
<HR>
<P><risposta di Claus Heine>
<P>
<P>
<HR>
<A HREF="Ftape-HOWTO-12.html">Avanti</A>
<A HREF="Ftape-HOWTO-10.html">Indietro</A>
<A HREF="Ftape-HOWTO.html#toc11">Indice</A>
</BODY>
</HTML>
