Autor Thema: Kobold Funktionsweise und Unterstützung für alternative Dateisysteme  (Gelesen 7713 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
EDIT Johannes: OFF-Topic ausgegliedert von http://forum.atari-home.de/index.php?topic=13996.0

Kobold kopiert nicht sektorweise, sondern dateiweise.
« Letzte Änderung: Mi 20.12.2017, 10:16:20 von Johannes »
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline gh-baden

  • Benutzer
  • Beiträge: 1.967
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.
« Letzte Änderung: Mi 20.12.2017, 05:39:13 von gh-baden »
Wider dem Signaturspam!

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
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.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline gh-baden

  • Benutzer
  • Beiträge: 1.967
{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.
Wider dem Signaturspam!

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
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.
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
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.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline Gaga

  • Benutzer
  • Beiträge: 2.554
  • Wer nicht nachfragt, bekommt auch keine Antwort!
Ich habe es bisher noch nicht probiert: läuft Kobold in höheren Auflösungen als ST High?
ask for: Thunder/TurboThunder- Storm TT/ST - Lightning VME/ST - Cloudy - Speedy - TwiSTEr

https://wiki.newtosworld.de/index.php?title=ThunderStorm_Extensions

Offline Johannes

  • Administrator
  • *****
  • Beiträge: 1.844
  • ATARI-HOME.DE - online for more than 20 years...
Zumindest die Version 3.5 läuft auf meinem Falcon in 1920x1080 problemlos.
Falcon060 /w SV - TT030 - Mega STE4 - Mega ST4 - 1040 ST(F/M) - Lynx II - Portfolio
non-Atari: DEC Vaxstation 4000 VLC, SGI Fuel, SGI Octane, SGI Indigo 2 R10K, SGI Indy, Casio PB-1000

Offline KarlMüller

  • Benutzer
  • Beiträge: 412
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.

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
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
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Mal testen...
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline mfro

  • Benutzer
  • Beiträge: 1.637
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?
And remember: Beethoven wrote his first symphony in C

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Ich konnte damit zumindestens Sachen vom ZIP-Laufwerk auf das Ext2 Laufwerk kopieren.Ich weiß aber nicht mehr wie lang die Dateinamen waren.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline mfro

  • Benutzer
  • Beiträge: 1.637
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.
And remember: Beethoven wrote his first symphony in C

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
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.
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
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.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
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.
« Letzte Änderung: Sa 13.01.2018, 05:35:58 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline mfro

  • Benutzer
  • Beiträge: 1.637
... 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
FS_WB_ENABLE="D"
den Cache für ausgesuchte Laufwerke überhaupt einschalten und mit
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).

« Letzte Änderung: Sa 13.01.2018, 08:22:24 von mfro »
And remember: Beethoven wrote his first symphony in C

Offline Gaga

  • Benutzer
  • Beiträge: 2.554
  • Wer nicht nachfragt, bekommt auch keine Antwort!
Interessant. Der Cache ist stets im Fastram?
ask for: Thunder/TurboThunder- Storm TT/ST - Lightning VME/ST - Cloudy - Speedy - TwiSTEr

https://wiki.newtosworld.de/index.php?title=ThunderStorm_Extensions

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Muss man da für jedes Laufwerk eine Zeile nach dem Motto "FS_WB_ENABLE="D"" schreiben oder ginge auch "FS_WB_ENABLE="CDEFGHIJKL""
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!