Re: tape woes (KOTZ!)

As Martin Cracauer wrote:

> > Du hast da etwas missverstanden. Zum einen ist ein tar/dd/dump
> > wesentlich performanter, wenn man die Blockgroesse ausreizt und

Das ist übrigens nur bedingt richtig. Es bringt einiges an
Performance, wenn man gerade bei cpio von der default Blockgröße von
512 Bytes nach oben geht. Aber schon der Unterschied zwischen 10 KB
und 32 KB ist ziemlich gering, noch größere Blockung bringt keine
nennenswerte Verbesserung mehr.

> Ich glaube, Du verstehst hier etwas miss, es geht hier nicht um die
> Applikation, die Probleme hat, sondern schon der Kernel kann einen zu
> langen Tapeblock nicht lesen. Zumindest meldet mein Kernel das :-)

Ja, das hängt damit zusammen, das physio(9) letztlich keine größeren
Hardwareblöcke (bzw. Pseudo-Hardwareblöcke) einlesen kann, als die
maximale physio-Größe des jeweiligen Gerätes. Früher war diese Größe
auf 64 KB beschränkt, mittlerweile ist die Landschaft etwas
unübersichtlicher. Wenn ich das jetzt richtig sehe, kann erstmal
jeder Treiber seinen eigenen maximal zulässigen Wert eintragen, man
kann da die Treiberquellen mal nach `si_iosize_max' greppen. Falls
nichts anderes vorgegeben, scheint 64 KB (DFLTPHYS aus
<machine/param.h>) die Voreinstellung zu sein, kein Treiber kann/darf
mehr als MAXPHYS (128 KB, auch in <machine/param.h>) verlangen.

Hat man nun beispielsweise ein altes IRIX-Tape (die waren mal der
Meinung, ,,viel hilft viel'' und schrieben unabhängig von der Blockung
der jeweiligen Applikation grundsätzlich 256 KB Blöcke auf Tapes),
dann hat man unter FreeBSD keine Chance, das Tape überhaupt zu lesen,
da kein Treiber einen so großen Block verarbeiten kann.

Daß es eine Größenbeschränkung geben muß, hat technische Ursachen.
Die 64 KB beispielsweise waren die Beschränkung der AHA154x-Adapter
auf 16-Scatter-Gather-Segmente, die jeweils eine physische Page (4 KB)
fassen können. Andere Adapter haben andere Beschränkungen.

> Deine Behauptung, dass die Blockgroesse auswirkungen auf den
> Kompressionsfaktor hat, ist m.E. auch Unsinn, die Kompression des
> tapes geschiet nicht auf Basis der von der Software gelieferten
> Bloecke.

Das ist richtig. ,,richtige'' variable Blockung gab es zuletzt bei
den reel-to-reel-Halbzoll-Tapes, die einige von uns wohl noch ganz gut
kennen... Alle heutigen Tapelaufwerke gaukeln auf der Schnittstelle
(SCSI oder wer sich's unbedingt antun will halt ATA) vor, variable
Blöcke zu können, sie können diese Illusion auch auf dem Datenträger
so transportieren, daß beim Auslesen ein Block identischer Länge
wieder gelesen wird. Intern blocken sie aber dennoch mit Blöcken von
vielleicht einem (DDS) oder einigen wenigen (DLT) Kilobyte Nutzdaten,
die dann noch mit hinreichend viel ECC-Daten aufgefüllt und aufs Band
geschrieben werden. Je nach Intelligenz können mehrere kleine Blöcke,
die von der Applikation geliefert werden, u. U. in einen Tapeblock
gepreßt werden (z. B. DDS oder DLT), oder aber sie belegen jeweils
einen eigenen Tapeblock, verschwenden also Platz (QIC >= 525, mit der
Ausnahme, daß zwei 512-Byte-`fixedlength'-Blöcke in einen 1 KB
Tapeblock passen). Eine eventuelle Kompression erfolgt dann ebenfalls
im Rahmen der Tapeblöcke.

Die Illusion, daß Blöcke variabler Länge aufgezeichnet werden können,
wird dadurch vermittelt, daß die Aufzeichnungsblocklänge ebenfalls mit
auf dem Tape gespeichert wird.

> Deine Behauptung, dass FreeBSD ein maximum von 64KB fuer
> Tape-Blockgroessen hat, ist m.E. auch Quatsch.

Je nach Treiber trifft sie u. U. zu, s. o. Liegt nicht im Tapetreiber
begründet, sondern in den zugrundeliegenden Hardwaretreibern, da diese
das physio-Limit festlegen.

> > >Unsinn. In sa(4) ist der Sachverhalt von variabler und fester
> > >Blockgröße im Abschnitt BLOCKING MODES genau beschrieben.

Zu beachten ist, daß der Autor dort von `logical blocks' spricht,
das sind also die Blöcke, die über das (SCSI-)Interface transferiert
werden.

Matt Jacob hat übrigens ziemlich antiquierte Vorstellungen von
heutigen QIC-Laufwerken, insofern ist seine Meinung über ``Most
QIC-type devices run in fixed block-size mode'' mit dem üblichen
Körnchen Salz zu genießen. Sie traf in dieser Form auf QIC <= 150 zu,
moderne QIC-Laufwerke stehen ihren DDS- oder DLT-Kollegen in Bezug auf
das verarbeitbare logische Blockformat fast in nichts nach (und das
Wörtchen ,fast' resultiert am ehesten aus der genannten Unfähigkeit,
mehrere kleine logische Blöcke in einen Tapeblock zu quetschen, aber
bei vernünftigen logischen Blockgrößen braucht man dieses Feature auch
nicht wirklich).

-- 
J"org Wunsch					       Unix support engineer
joerg_wunsch@interface-systems.de         http://www.interface-systems.de/~j
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message