aktueller FAT32 Treiber?

[Martin Vieregg]

Ich habe Probleme, auf meiner FAT32 Festplattenpartition (ArcaOS 5.0.2) größere Datenmengen >200MB zu schreiben. Die Kommandozeile friert dabei ein, ich muss runterfahren, unter Windows einen chkdsk d: /F Lauf machen, manchmal geht es dann, oft aber immer noch nicht. Es scheinen nicht alle FAT32 Laufwerke betroffen zu sein, ich kopiere dann die betreffende Dateien auf einen FAT32-USB-Stick.

Code: Alles auswählen

Directory of C:\OS2\BOOT
20.05.18 13.01        138.706    124 a---  fat32.ifs

Kann ich ein Update laden? Seit es von Netlabs von von ArcaOS eine Version gibt, kenne ich mich nicht mehr aus.

Bei YUM ist ja der FAT32 Treiber in der Aktualisierungsliste glaube ich nicht dabei.

[aschn]

Eine Möglichkeit wäre alle neuesten Treiber von AN zu installieren und dann den AN-Bugtracker zu füttern.

[MikeK]

Welche Treiberversion ist den im Einsatz Netlabs oder AN? Wer lesen kann ist klar im Vorteil. Mike

Ich benutze von Netlabs die FAT32-Treiber aus zwei Gründen:
1. sie sind in etwas 3x so schnell beim Schreiben
(dazu gibt es auch einen Thread beim OS2World-Forum: https://www.os2world.com/forum/index.ph ... l#msg29398)
2. sie beinhalten exFAT-Unterstützung, was bei größeren SD-Karten für meine Kamera Standard ist

Grüße aus Potsdam,
Mike

[DonLucio]

Ich habe Probleme, auf meiner FAT32 Festplattenpartition (ArcaOS 5.0.2) ...

Code: Alles auswählen

Directory of C:\OS2\BOOT
20.05.18 13.01        138.706    124 a---  fat32.ifs

Ich habe eine etwas jüngere, aber schlankere Version im Einsatz:

Code: Alles auswählen

Directory of C:\os2
17.08.18 17.15        116.433      0 a---  fat32.ifs

Ich weiß nicht mehr, woher ich die habe...

Woran ich mich aber noch erinnere, ist, dass ich anfangs auch etliche Probleme hatte, bis ich die FAT32-Medien (SD-Karte etc.) mit DFSee (Ver. 1.42) formatiert habe. Was imho auch sowieso Voraussetzung ist für Medien größer als 32 GB.

Eine frisch gekaufte 128GB-SDCard muß ich zuvor mit DFSee formatieren, dann klappt's aber auch damit. Größere habe ich noch nicht probiert.
Ob das auch mit Festplatten-Partitionen funktioniert, habe ich nicht ausprobiert, denke aber, dass ja.

Das ist natürlich keine Lösung für Medien, die schon mit Daten aus der Windows-Welt daherkommen. Da hilft möglicherweise:
* Frische SDCard mit DFSee formatieren
* Daten von alter SDCard auf die neue kopieren (unter Win)
* Dann die alte bei eBay verkaufen, nur noch die neue (DFSee-formatierte) benutzen.

Seit es von Netlabs und von ArcaOS eine Version gibt, kenne ich mich nicht mehr aus.

Geht mir ähnlich ...

Gruß,
Don Lucio.

[Martin Vieregg]

Hallo Don Lucio,

ich formatiere meine FAT32-Partitionen auch mit DFSEE. Die betroffene ist eine 64 GB Partition. Hast Du eine neue AN Version oder eine Netlabs-Version? Die obigen Kommentare hören sich so an, dass man die neueste Netlabs-Version installieren sollte. Geschwindigkeit ist mir schon sehr wichtig.

[Andi B.]

Den Unterschied zwischen den beiden Versionen würde ich grob so beschreiben - die letzte Netlabs Version hat mehr Features (auch solche welche lizenzrechtlich fraglich sind), die von AN kompilierte Version ist auf die Kernfunktionen abgespeckt, aber auch deutlich besser getestet. FAT32 ist und war unter OS/2 immer sehr langsam. Ob da eine der Versionen schneller ist und unter welchen Umständen (cache, Stick, HDD, USB, SATA...) weiß ich nicht. Langsam ist es immer. Ich meine damit größer Faktor 10 gegenüber z.B. JFS. Das ist für viele Anwendungsfälle kein Problem, man sollte es aber wissen.

Bei der AN Version hat man die Chance, dass ein Fehler gefixed wird wenn man sie unter ArcaOS betreibt und den Fehler reproduzieren kann. Bei der Netlabs Version hat man die Chance, dass ein weiteres halbgetestetes Feature mit ev. Mehrwert in speziellen Anwendungsfällen eingebaut wird.

[MikeK]

... Ob da eine der Versionen schneller ist und unter welchen Umständen (cache, Stick, HDD, USB, SATA...) weiß ich nicht. Langsam ist es immer. ...

Ja, langsamer als JFS ist der FAT32 ohne Frage. Allerdings kommt man nicht drum herum. Sei es wegen Datenaustausch mit einer Win-Installation auf dem gleichen Rechner, oder aber wegen SD-Karten für Digitalkameras / USB-Sticks.

Ja, AN hat bedenken wegen dem exFAT-Teil in den Netlabs-Treibern und will da möglichen Ärger mit MS vermeiden.

Geschwindigkeitsunterschied Netlabs vs. AN-Treiber:
Ich habe bei mir beide Treiber getestet. Der Netlabs-Treiber ist ca. 3x schneller als der AN-Treiber.
Dabei sind folgende Einstellungen in der config.sys nötig:
ifs=x:\OS2\BOOT\fat32.ifs /cache:0 /h /q /ac:* /largefiles /fat /exfat
REM call=x:\OS2\cachef32.exe /f /p:2 /m:50000 /b:250 /d:5000

Also den Cache komplett abschalten!

Grüße aus Potsdam,
Mike

[erdmann]

Hast du auch BEIDE Versionen mit abgeschaltetem Cache verglichen?
Ich kann mir nicht vorstellen, dass AN so furchtbar viel angefasst hat. Ich hätte gedacht, die haben nur das eine oder andere Problem mit dem Cache behoben. Wenn der abgeschaltet ist, sollte das ja zu keinem Unterschied fùhren.

[MikeK]

Hast du auch BEIDE Versionen mit abgeschaltetem Cache verglichen?

Mmmmh, ich glaube mich zu erinnern, dass ich unter gleichen Bedingungen getestet hatte, bin mir da aber nicht mehr sicher. Ist halt schon 'ne Weile her.


Ergänzung: habe gerade noch mal auf meinem X250 getestet.

#1) Wenn man bei den AN-Treibern den Cache auf 0 setzt und dann CALL von cachef32.exe ausremt geht noch Lesen von Dateien von der FAT32-Partition, aber nicht mehr Schreiben.

#2) Habe mit zwei verschiedenen Szenarien getestet:
1x einen Ordner kopiert (1876 Dateien) Gesamtgröße 348.976 KB
1x eine große Datei (AOS506.7z), Größe 1.121.876 KB
Jeweils von JFS nach FAT32 kopiert.

Ergebnis ist uneindeutig:
Test 2.1: Ordner kopieren: Netlabs-Treiber 6:52 min - AN-Treiber: 2:46 min
Test 2.2: große Datei: Netlabs-Treiber: 0:35 min - AN-Treiber: 2:48 min

Es sieht also für mich jetzt so aus, als ob AN den Treiber auf viele kleine Dateien (häufiger Zugriff auf den File Allocation Table) optimiert hat und der Netlabs-Treiber bei großen Dateien vorteilhaft ist.

Ergänzung II:
habe den Test mit den Netlabs-Treibern und eingeschalteten Cache noch mal nachgeholt:
Test 3.1 Ordner kopieren: Netlabs-Treiber mit Cache: 9:09 min - Netlabs-Treiber ohne Cache: 6:52 min - AN-Treiber: 2:46 min
Test 3.2: große Datei: Netlabs-Treiber mit Cache: 2:17 min - Netlabs-Treiber ohne Cache: 0:35 min - AN-Treiber: 2:48 min

Also bringt das Einschalten des Caches bei den Netlabs-Treibern keine Verbesserung. Im Gegenteil bei der großen Datei wird es schlechter.

Grüße,
Mike

[LutzG]

Hmm,
hab ich früher auch mal getestet, und ohne Cache lief es etwa 3-5mal schneller (Warp 4 und ecs).
Ich meine aber, daß der Cache für die Umwandlung von Zeichencodes OS/2 <-> Win zuständig war.

Ist das heutzutage auch noch so?

fragt sich
Lutz

[erdmann]

Hmm,
hab ich früher auch mal getestet, und ohne Cache lief es etwa 3-5mal schneller (Warp 4 und ecs).
Ich meine aber, daß der Cache für die Umwandlung von Zeichencodes OS/2 <-> Win zuständig war.

Ist das heutzutage auch noch so?

fragt sich
Lutz

Nein, der Cache wird nicht für die Umwandlung von Zeichen gebraucht. Der Cache ist ein Datei- und Verzeichniscache.

[Andi B.]

Ich hab schon auch sowas im Hinterkopf. IIRC hat Rudi mal geschrieben, man sollten den cache mit einem Parameter sehr wohl in der config.sys lassen. Muss mal nachsehen ob ich die Aufzeichnung dazu noch finde.

[erdmann]

Ich habe vor Jahren mal an FAT32.IFS gearbeitet (unter anderem am EA support und zur Beschleunigung von Lesen/Schreiben beim direkten Plattenzugriff, also nicht Cache). Ich kann mich noch grob daran erinnern, dass es zwei Probleme mit dem Cache gibt:

1) die Verdrängungslogik beim Lesen und Schreiben ist nicht unbedingt clever gewählt. Das ist auch nicht einfach, da geht es darum, wie oft ein Sektor angefasst wird, in welcher Art (Lesen oder Schreiben) und wann dies das letzte Mal passiert ist (also grob: Zeit und Häufigkeit und eventuell Bevorzugung von Lesen vor Schreiben oder umgekehrt). Die "least recently used" Sektoren sollten verdrängt werden aber "least recently used" muss eben mit Leben gefüllt werden. Das kann man extrem aufwändig gestalten, in dem man eine umfangreiche Historie führt (wird öfter auf bestimmte Plattenbereiche zugegriffen ? etc.) mit gutem statistischem Ergebnis oder einfacher gestrickt mit schlechterem statistischen Ergebnis.

2) Der Cache trennt nicht zwischen Dateien und Verzeichnissen. Diese beiden Dinge haben aber keinen Bezug, ergo sollten diese in zwei getrennten Cachebereichen behandelt werden . Es ist halt schlecht, wenn der Cacheinhalt einer sehr großen Datei verdrängt wird durch viele Verzeichniszugriffe (z.B. "dir") zwischendurch. Das eine hat eben mit dem anderen nichts zu tun.

[Andi B.]

REM cachef32.exe /S /F It's preferrable to replace "/F" with "/N" instead of remming out the line completly. Otherwise the codepage translation table will not be initialized correctly

Meine Notiz dazu. Allerdings ohne Quellenangabe.