GEMini Atari/GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso/files/diskutil/gemar/docs/fragen.txt

Text File | 1993-04-12 | 8KB | 147 lines

Fragen zu GEMAR, und Ihre Antworten:

F:  Warum braucht GEMAR manchmal so lange, wenn man einen Index von einem
    Band einliest?
A:  GEMAR legt aus Gründen der Datensicherheit den Index hinter dem Backup
    ab. Dies ist nötig, damit bei einem evtl. aufgetretenen Fehler beim
    Sichern der Dateien, dieser Fehler im Index protokolliert werden kann.
    Um den Index schnell zu erreichen, schreibt GEMAR auch vor den Daten
    einen Index, und vermerkt später in der Datei GEMAR.KEY, ob dieser Index
    gültig ist.
    Wenn beim Restore der vordere Index ungültig ist, wired der hintere
    gelesen, was eine Weile dauern kann.

F:  Warum spult mein Streamer das Band während des Backups manchmal ein
    Stück zurück, und wieder vor?
A:  Wenn der Streamer nicht schnell genug mit Daten versorgt wird, hält er
    an, bis wieder Daten vom Computer geliefert werden. Da ein Streamer
    jedoch sehr schnell läuft, und daher eine große Lücke zwischen den
    Daten entstehen würde, spult er ein Stück zurück, was leider sehr viel
    Zeit benötigt.
    Bei GEMAR sollte dies eigentlich nur ab und zu passieren. Dazu sollten
    die Puffergröße und die Datenrate möglichst genau angepasst werden.

F:  Warum hält mein Streamer während des Backup manchmal für eine Weile an?
A:  Leider ist es manchmal nicht möglich, die Daten von der Festplatte so
    schnell zu lesen, wie der Streamer Sie benötigt.
    Daher füllt GEMAR erstmal seine gesamten Pufferspeicher, bevor er
    wieder Daten an den Streamer schreibt. Währenddessen wartet der
    Streamer dann.

F:  Warum kann ich bei GEMAR nicht eine Sicherung der belegten Sektoren
    meiner Festplatte durchführen?
A:  GEMAR wurde auf höchste Datensicherheit hin konzipiert. Daher ist es
    sinnvoll die Dateien von der Festplatte nur über das Betriebssystem
    einzulesen. Dadurch hat GEMAR auch bei einem neuen, erweiterten
    Datenformat auf einer Festplatte  keine Problem mit der Sicherung der
    Daten. Solange man die Dateien vom Desktop aus benutzen kann, kann auch
    GEMAR sie sichern.

F:  Warum sind bei GEMAR die Flags 'Load to Fast-RAM' und 'Allocate Fast-RAM'
    nicht gesetzt?
A:  Wenn GEMAR mit einem Streamer betrieben wird, der am DMA-Port des TT
    angeschlossen ist, so müßten die Daten über einen Zwischenpuffer, den
    sogenannten 'Fast-RAM-Buffer' an den Streamer geschickt werden.
    Da dies zu viel Zeit kosten würde, unterstützt GEMAR diese Möglichkeit
    nicht.
    Falls der Streamer am SCSI-Port des TT hängt, so können die Flags
    eingeschaltet werden.

F:  Warum ist das Streamericon nicht anwählbar, wenn ich einen Index von der
    Platte eingelesen habe?
A:  Es kann immer nur ein Index von Platte, oder von Band eingelesen werden.
    Daher kann der Streamer nicht angewählt werden, wenn ein Plattenindex
    gelesen ist und umgekehrt.

F:  Warum kann GEMAR sein Desktop nicht in ein Fenster legen? Unter
    MultiTOS/MultiGEM/Mag!X ist das sehr störend.
A:  Ganz einfach: GEMAR läuft zwar prinzipiell unter einem Multi-Tasking-
    System, aber es ist sehr gefährlich, unter Multitasking ein Backup
    durchzuführen, während andere Programme evtl. Daten auf der Festplatte
    ändern. Daher sollte GEMAR _grundsätzlich_ allein laufen und kann damit
    ein eigenes Desktop behalten.

F:  Warum kann ich kein Image-Backup der gesamten Platte machen?
A:  Das Problem liegt darin, daß man nicht so einfach die Größe der Fest-
    platte ermitteln kann. Mittels Mode-Sense erhält man nicht immer die
    richtigen Werte und Read-Capacity funktioniert nicht mit jeder
    Festplatte und jedem SCSI-Adapter.

F:  Warum kann ich nicht einfach ein Laufwerksicon auf das Streamericon
    ziehen, damit die Daten gesichert werden?
A:  Auf diese Weise kann beim Restore nicht sicher erkannt werden, ob die
    Daten unter ihren Original-Pfaden, oder in einen Zielpfad gesichert
    werden sollen, bzw. Beim Backup, ob es ein Full- Daily- oder Incremental
    werden soll.
    Daher wurde gänzlich auf das ziehen von Icons verzichtet.

F:  Muß ich vor einem Backup das Band löschen?
A:  Eigentlich nicht. Ein SCSI-Streamer arbeitet normalerweise so, daß das
    gesamte Band gelöscht wird, wenn das Band vom Anfang ausgehend
    beschrieben wird.  Bei einigen exotischen Streamern könnte es sein, daß
    dies notwendig ist, ansonsten ist es nur unnötiger Zeitverbrauch.

F:  Für den Streamer werden immer 4 Festplattenlaufwerke angemeldet. Woran
    liegt das?
A:  Einige Festplattentreiber kontrollieren, ob ein SCSI-Gerät ein
    wechselbares Medium hat. In diesem Fall geht ein solcher Treiber davon
    aus, daß es sich um eine Wechselplatte handelt und meldet dafür 4
    Partitionen an, damit ein später eingelegtes Medium benutzt werden kann.
    Damit dies nicht immer passiert, muß der Plattentreiber so konfiguriert
    werden, daß der Streamer nicht beachtet wird.
    Für AHDI verwenden Sie am besten das Programm HDPATCH und melden die
    SCSI-Adresse ab, auf der der Streamer liegt (Optionen, CUSTOM SCSI/ACSI).
    Wenn Sie HUSHI verwenden, benutzen Sie das Programm SCSITOOL, wählen
    darin den Menüpunkt 'Treiber/Konfigurieren' (oder CONTROL-K). Daraufhin
    erscheint ein Dialog, in dem ein Button 'Gerätereihenfolge' liegt. Nach
    Anwählen dieses Buttons kommen Sie in einem Dialog, in dem Sie die
    Adresse des Streamers abmelden können (anklicken). Danach sagen Sie 'OK',
    im ersten Dialog wieder 'OK', dann auf die Frage 'Einstellungen in
    HUSHI.SYS speichern?' noch mit 'Ja' antworten, und fertig.

F:  Wie finde ich am einfachsten die für meinen Streamer nötigen Parameter?
A:  Ich persönlich habe mit folgender Vorgehensweise gute Erfahrungen gemacht:

    -Buffergröße auf den im Streamer-Handbuch angegebenen Wert (evtl. interne
     Abzüge berücksichtigen)
    -Datenrate auf den Wert des Streamers + 25 %
    -Zeit vor SCSI aus
    -Wait vor/nach SCSI unverändert
    -Verbose on
    -Ein Backup durchführen. Wenn dabei der Streamer anhält, solange der
     Puffer- Balken nicht auf 0 ist, dann ist die Datenrate zu klein. Läuft der
     Puffer immer leer, mal mit niedrigerer Datenrate versuchen.
    -Man sollte auch mal sehen, wie sich 'Wait vor/nach SCSI' verhält. Am TT
     sollte man die Werte eigentlich auf 0 einstellen können. Ansonsten einfach
     mal auf 0, und dann sehen, ob Fehler auftreten. Kommt eine Fehlermeldung
     von GEMAR (KommandoTimeout), muß Wait vor SCSI hochgedreht werden. Kommt
     die Meldung vom etv_crit (Daten auf Diskette), dann muß Wait nach SCSI
     hochgedreht werden.
    -Unter Umständen kann auch ein zu niedriger Wert für Wait nach SCSI dazu
     führen, daß der Plattentreiber Retries durchführen muß, was daran zu
     erkennen sein sollte, daß die Datenrate schlagartig abfällt.

    Im Allgemeinen ist es ein Geduldsspiel, bis man die richtigen Parameter
    gefunden hat.

    Sollte es nicht klappen, den Streamer im Streamen zu halten, so sollte man
    die Buffergröße auf 0 stellen, damit immer ein möglichst großes Segment
    gefüllt wird, bevor es an den Streamer geschickt wird.

F:  Wenn ich ein Restore von Laufwerk C: mache, und anschließend eines von
    Laufwerk D: spult der Streamer immer zurück, bevor er die Daten von D:
    restauriert. Warum tut er das?
A:  Aufgrund der Pufferstrategie von GEMAR befindet sich das Band schon ein
    Stück im Datenbereich von Laufwer D:. Da leider nicht alle Streamer ein
    Space rückwärts beherrschen, muß daß Band zurückgespult, und vom Anfang
    ausgehend mit Space die richtige Stelle angesteuert werden.

F:  Nachdem ich meine Platte umpartitioniert habe, hat GEMAR beim Restore
    immer den hinteren Index verwendet. Warum benutzt er nicht den vorderen
    (korrekten) Index?
A:  GEMAR hat in der Datei GEMAR.KEY den Schlüssel geschrieben, daß bei
    diesem Backup der vordere Index verwendet werden kann. Daher sollte man
    in dem Fall, daß man umpartitionieren will, die Datei auf Diskette
    sichern, damit beim Restore der Schlüssel für dieses Backup auch vorhanden
    ist.