Kobold Funktionsweise und Unterstützung für alternative Dateisysteme

[1ST1]

EDIT Johannes: OFF-Topic ausgegliedert von http://forum.atari-home.de/index.php?topic=13996.0

Kobold kopiert nicht sektorweise, sondern dateiweise.

[goetz @ 3rz]

Kobold kopiert nicht sektorweise, sondern dateiweise.

Kobold kopiert Dateien sektorweise, wenn es das kann (auf Standard FAT12 und FAT16-Systemen).

Und Kobold kopiert Dateien dateiweise mit den GEMDOS-Funktionen, wenn es ein nicht-FAT16-System ist.

[1ST1]

Kobold kopiert nicht sektorweise, sondern dateiweise.

Kobold kopiert Dateien sektorweise, wenn es das kann (auf Standard FAT16-Systemen).

Und Kobold kopiert Dateien dateiweise mit den GEMDOS-Funktionen, wenn es ein nicht-FAT16-System ist.

Es kopiert trotzdem Dateien. Es richtet sich nach der Dateistruktur. Es nutzt nur seine eigenen (schnelleren) Routinen um die Daten zu lesen und schreiben, wenn der GEMDOS Modus nicht an ist. Um genau zu sein, ist das ein Zwischending. Aber reines sektorweises Kopieren wäre eine 1:1 Kopie der jeweiligen Partition, je nach Intelligenz mit oder ohne Berücksichtigung von als im Dateisystem leer markierten Sektoren.

[goetz @ 3rz]

{Kobold} […] Es kopiert trotzdem Dateien. Es richtet sich nach der Dateistruktur.

Genau. Und dafür nutze ich ihn, weil bei meinem beschriebenen Anwendungsfall das alles ist, was ich will, auf meinen Atari-Platten sind nur Dateien und Ordner, und ein Bootsektor, den ich in ein paar Sekunden mit HDDRUTIL neu geschrieben habe. Leere Sektoren oder Datenmüll von gestern (lies: nicht entfernte Dateien, die nur aus der FAT ausgetragen sind) will ich nicht kopieren.

Es nutzt nur seine eigenen (schnelleren) Routinen um die Daten zu lesen und schreiben, wenn der GEMDOS Modus nicht an ist. Um genau zu sein, ist das ein Zwischending. Aber reines sektorweises Kopieren wäre eine 1:1 Kopie der jeweiligen Partition, je nach Intelligenz mit oder ohne Berücksichtigung von als im Dateisystem leer markierten Sektoren.

Jop. Und das kann man bspw. mit Diskus machen – oder, nach deiner Beschreibung, mit alten Versionen von HDDRUTIL. Obwohl ich Betatester war, war mir diese Funktion nie aufgefallen, da nie benötigt. Ich mach kopiere keine Atari-Medien sektorweise, weil mein Anwendungsfall ein anderer ist, ich will nur meine Daten haben, und da tut Kobold ganz prima.

[ari.tao]

Kobold kopiert Dateien sektorweise, wenn es das kann (auf Standard FAT16-Systemen).
Und Kobold kopiert Dateien dateiweise mit den GEMDOS-Funktionen, wenn es ein nicht-FAT16-System ist.

Ja, traurig, daß es für Kobold kein Update auf FAT32 gibt.

[1ST1]

Kobold kann leider auch nicht auf das Laufwerk U: zugreifen. Damit ist für Kobold ein per nfs gemountetes Serververzeichnis nicht erreichbar. Vielleicht sollte man sich mal um die Quellen von Kobold bemühen und all das verbessern.

[Gaga]

Ich habe es bisher noch nicht probiert: läuft Kobold in höheren Auflösungen als ST High?

[Johannes]

Zumindest die Version 3.5 läuft auf meinem Falcon in 1920x1080 problemlos.

[KarlMüller]

Zumindest die Version 3.5 läuft auf meinem Falcon in 1920x1080 problemlos.

Und in dieser Version kann auch die Größe verändert werden.

Ansonsten benötigt er laut Handbuch zur 2.0 mindestens eine Auflösung von 640x200.

[ari.tao]

Kobold kann leider auch nicht auf das Laufwerk U: zugreifen. Damit ist für Kobold ein per nfs gemountetes Serververzeichnis nicht erreichbar. 

Vielleicht hilft ein
   alias p: u:\nfs
oder ein
  sln u:\nfs c:\mint\nfs

[1ST1]

Mal testen...

[mfro]

Mal testen...

... das kannst Du dir getrost sparen, meine ich.

Wieso soll Kobold ausgerechnet auf ein NFS-Dateisystem zugereifen können, wenn's nicht mal ext2fs, minixfs oder FAT32 unterstützt?

[1ST1]

Ich konnte damit zumindestens Sachen vom ZIP-Laufwerk auf das Ext2 Laufwerk kopieren.Ich weiß aber nicht mehr wie lang die Dateinamen waren.

[mfro]

Ich konnte damit zumindestens Sachen vom ZIP-Laufwerk auf das Ext2 Laufwerk kopieren.Ich weiß aber nicht mehr wie lang die Dateinamen waren.

Dann aber nur über die GEMDOS- (MiNT-) Funktionen. Dann kannst Du auch den (irgendeinen) Desktop (oder gleich cp) nehmen.

[ari.tao]

Genau.
Es ging mir aber darum zu zeigen, wie man die Beschränkung des Kobold auf die ersten 16 Partitionen umgehen und dann zB. auf einem Z: mit FAT16 benutzen kann.

[1ST1]

Ich bin mir gerade nicht sicher, ob das wirklich eine Beschränkung auf 16 Laufwerke ist, ich bin gerade zu weit weg von den Rechnern, aber ich meine - so aus der Entfernung - in Kobold sind in den Auswahlboxen durchaus die Buchstaben bis Z hinterlegt, aber die Laufwerke die es nicht erkennt, sind grau. Vielleicht finde ich heute Abend Zeit, mir das noch mal anzusehen und auch das mit den Symlinks zu testen. Für das Laufwerk muss ich dann aber wahrscheinlich den GEMDOS-Modus einschalten, was unter MiNT vielleicht generell eine gute Idee ist.

[ari.tao]

Oh, sorry, das mußte natürlich 26 (ie. bis z) heißen, nicht 16. MiNT kann 6 mehr, nämlich 1 - 6, aber der Kobold leider nicht. Und u blendet er auch aus.
Meine Vorschläge aus #9 taugen beide nix. Links kann der Kobold zwar kopieren, aber nicht auflösen. Und Aliasen auf Ordner in u kann man leider auch nicht setzen (zumindest nicht in mint.cnf  bis MiNT_1.15.9, hab´s gerade ausprobiert.)
Der GEMDOS-Modus des Kobold ist völlig unabhängig vom OS, ie. hängt nicht von MiNT ab, sondern nur vom FS auf den jeweiligen Partitionen der Kopier-Aktion. Man muß den nicht vorweg einstellen, denn der Kobold fragt ggf. nach. Benutzt man abwechselnd unterschiedliche Platten, ist die Voreinstellung sogar hinderlich.
Wenn ich zuvor weiß, daß ich von/auf einer Nicht-F16-Partition kopieren will, benutze ich den/einen Desktop (wie von mfro beschrieben). Das ist dann leider seeehr langsam.

[mfro]

... Das ist dann leider seeehr langsam ...

Wenn man MiNT benutzt, ist Kobold (bezüglich Geschwindigkeit) m.E. sowieso eher kontraproduktiv. Kobold zieht seine Geschwindigkeit aus zwei Sachverhalten:

• dem (mehr oder weniger "intelligenten" Umgang mit GEMDOS-Strukturen
• der Tatsache, dass es soviel wie möglich an Information im Speicher hält anstatt sie immer wieder von der Platte zu lesen oder in "Mini-Häppchen" darauf zu schreiben

Der erste Punkt lässt sich (vom Endanwender) bei TOS/MiNT nicht verbessern, der zweite schon. "normales" TOS hat einen Schreib-/Lese-Cache, der eigentlich nicht erwähnenswert ist. Bei jedem geschriebenen Cluster wird die FAT upgedated, bei so gut wie jedem gelesenen muss die Quell-FAT (neu) eingelesen werden, um zu sehen "wo's weitergeht".
MiNT hat einen Festplattencache, der das (deutlich) verbessern kann. Wer genug Speicher hat, kann damit eine deutliche Beschleunigung der Dateioperationen erreichen.

Mal (in der MINT.CNF) mit

Code: [Auswählen]

FS_WB_ENABLE="D"
den Cache für ausgesuchte Laufwerke überhaupt einschalten und mit

Code: [Auswählen]

FS_CACHE_SIZE=<Grösse in KB>
ein paar MB (oder gleich ein paar hundert, wenn man hat) für den Cache bereitstellen. Insbesondere letzteres macht einen deutlichen Unterschied, je grösser, desto besser.

Auf der FireBee macht das z.B. für das Compilieren mit einem aktuellen gcc den Unterschied von "nicht benutzbar" zu "he, das ist ja richtig flott" aus. Ich habe da 200MB Disk cache eingestellt und so werden Spitzen-Schreib/Leseraten auf ext2fs von bis zu 30 MB/s (im Vergleich zu 1-2 MB/s mit der Standardeinstellung) erreicht.

Wie immer, gibt's nix auf der Welt umsonst. Erstens ist der Speicher weg (MiNT hat leider keinen "automatischen" Disk-Cache wie z.B. Linux (dort wird immer der gesamte, ungenutzte Hauptspeicher genutzt bis einer kommt, der ihn anderweitig braucht) und 2. sind u.U. die Daten weg, wenn die Kiste abstürzt (was noch nicht weggeschrieben war, ist bei einem Absturz verloren - aber das ist bei Kobold nicht anders).

[Gaga]

Interessant. Der Cache ist stets im Fastram?

[1ST1]

Muss man da für jedes Laufwerk eine Zeile nach dem Motto "FS_WB_ENABLE="D"" schreiben oder ginge auch "FS_WB_ENABLE="CDEFGHIJKL""