Martin's Privatmeinung

>Koenntest Du die Scheisse mit Subject: Antwort: unterlassen? Und das
>vor allem mehrfach. Glaubst Du, Du bist allein auf der Welt oder
>was?

Ich bin solche Faekalsprache nicht gewoehnt. Aber vielleicht moechtest
du uns allen mehr von dir zu Hause erzaehlen.

>Ich wuerd Dich ja gerne ins Killfile nehmen, aber Du redest so viel
>Unsinn, dass FreeBSD in Verruf kommen koennte, wenn Du nicht
>korrigiert wirst.

In diesem Falle solltest du jede Mail, in der meine Adresse als
Absender vorkommt *kommentarlos* loeschen. Es wird deine Lebens-
erwartung um Jahre verlaengern.

>> >> tar moechte beim zuruecklesen die Blockgroesse vom schreiben wissen,
>> >> falls man daran mit -b herumgedreht hat.
>> >
>>
>> Du hast da etwas missverstanden. Zum einen ist ein tar/dd/dump
>> wesentlich performanter, wenn man die Blockgroesse ausreizt und
>> zum anderen kommen die Programme in Schwulitaeten (buffer overflow)
>> wenn man mehr als die Standardgroesse benutzt hat und dieses beim
>> Wiedereinlesen nicht als Parameter beruecksichtigt. Diese gewaehlten
>> Blockgroessen werden dann an das SCSI-Subsystem weitergereicht,
>> zumindest zeigt systat das so an.
>
>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 :-)

(sa0:ahc0:0:5:0): 65536 byte tape record bigger than supplied buffer
Der kernel hat den Record gelesen und wird ihn an tar nicht los, weil
der buffer zu klein ist. Oder hast du eine andere Interpretation?

>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.

Leider wieder falsch. Da Kompression ein statistisches Verfahren ist,
erreicht man in groesseren Dateien (=Bloecke) bessere Kompressions-
raten. Lies mal man compress, letzter Absatz vor Diagnostics. Dieses
wird auch von der Praxis bestaetigt.

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

Das habe ich auch so nicht behauptet. Ich weiss nur, das ich in der
liste mal gelesen habe, das das SCSI-System maximal 64Kb grosse
Bloecke verarbeitet und darueber also kein Performancegewinn mehr
auf Platte oder Band zu erwarten ist. Darueberhinaus habe ich
nur die Vermutung geaeussert, das groessere Bloecke aufgesplittet
werden. Bitte naechstes Mal genauer lesen.

>Ich glaube, wir brauchen hier dringend mal jemanden, der eine Tape-FAQ
>verspeist und den ganzen Quatsch, der in diesem Thread gelabert wurde,
>korriert. Ist ja schrecklich. Ich hab Joerg mal CC'ed, der sollte
>sich einigermassen auskennen.

Ich moechte dir jetzt hier zum zweiten Mal empfehlen deinen Schreibstil
zu ueberdenken bzw. dir eine andere Liste zu suchen.

>> >> Die variable Blockgroesse, die man mit mt einstellen kann, hat
>> >> mit der Hardwarekompression zu tun.
>> >
>> >Unsinn. In sa(4) ist der Sachverhalt von variabler und fester
>> >Blockgröße im Abschnitt BLOCKING MODES genau beschrieben.
>>
>> Richtig, war leider ein Schnellschuss vom mir.
>
>Die variable Blocksize hat m.W. nicht das geringste mit Kompression
>oder Comprimierbarkeit zu tun,

Schoen, das du lesen kannst.

>sondern man braucht sie fuer bestimmte
>>Tape-Typen (z.B. die 9-Spur-Laufwerke), die komplett anders gesteuert
>>werden als moderne QIC, DAT oder DLTs.

Interessante Ansicht ;-)
Wie erklaerst du dir eigentlich das Vorhandensein von variablen
Blockgroessen bei DLT, DAT oder VXA ?

In Hoffnung deiner Besserung
Norbert

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 21 Nov 2000 - 17:23:13 CET