Software > Software (16-/32-Bit)

Kobold Funktionsweise und Unterstützung für alternative Dateisysteme

<< < (4/5) > >>

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:

--- Zitat von: ari.tao am Sa 13.01.2018, 05:32:12 ---... Das ist dann leider seeehr langsam ...

--- Ende Zitat ---

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 schreibenDer 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: ---FS_WB_ENABLE="D"

--- Ende Code ---
den Cache für ausgesuchte Laufwerke überhaupt einschalten und mit

--- Code: ---FS_CACHE_SIZE=<Grösse in KB>

--- Ende Code ---
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""

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete