News Rufus 4.16: Entwickler rechnet mit AMI wegen NTFS-Bug ab

[Caramon2]

ist auf einem usb-stick verschmerzbar.

Wie jedes FAT (exFAT ist quasi nur ein geringfügig erweitertes FAT64) muss es jede Änderung im FAT am Anfang schreiben: Also immer wieder auf die gleiche Stelle. - Auf Dauer tut das einem normalen Stick (keiner auf SSD-Basis, der Wear Leveling betreibt) schon "weh".

Dass exFAT für Flashspeicher optimiert sein soll, ist eine Lüge! (damit meine ich die Redmonster - Fipptehler beabsichtigt )

Informiere dich bitte über die Arbeitsweise von F2FS: Das ist Flashspeicheroptimierung!

Nachtrag:

Wäre exFAT wirklich für Flashspeicher optimieren, müsste es Datenträger auf die gleiche Art beschreiben: Alles hintereinander und erst wenn es das Ende erreicht, wieder von vorne in die durch's löschen inzwischen frei gewordenen Bereiche.

 

[mibbio]

Im verlinkten Thread kannst du nachlesen, dass ntfs inzwischen bis zu 2048 Kilobyte große Cluster ermöglicht: Wegen der hohen Plattenkapazitäten von z. B. Serverfarmen.

Hab ich ja auch nicht bestritten. Nur formatiert Windows meines Wissens standardmäßig immer noch mit 4K und 16K (oder noch größer) bietet das Formatierungstool von Windows glaube nichtmal an.

Heißt im Umkehrschluss, dass die meisten Leute ihre NTFS-formatierten Laufwerke schlicht weiterhin mit 4K großen Clustern nutzen, auch wenn es heutzutage nicht mehr unbedingt optimal ist.

 

[0x8100]

Informiere die bitte über die Arbeitsweise von F2FS: Das ist Flashspeicheroptimierung!

wer ist "die"? wer soll informiert werden? o_O und was bringt einem f2fs auf einem stick, der möglichst interoperabel sein soll?

 

[Caramon2]

Heißt im Umkehrschluss, dass die meisten Leute ihre NTFS-formatierten Laufwerke schlicht weiterhin mit 4K großen Clustern nutzen, auch wenn es heutzutage nicht mehr unbedingt optimal ist.

Das stimmt natürlich.

Würde es Windows schon von sich aus richtig machen, bräuchte ich es ja nicht empfehlen.

Ergänzung (Gestern um 16:21)

wer ist "die"? wer soll informiert werden?

Autokorrektur: Das sollte "dich" heißen.

o_O und was bringt einem f2fs auf einem stick, der möglichst interoperabel sein soll?

Es ging um die Funktionsweise, nicht um das Dateisystem.

Wäre exFAT wirklich für Flashspeicher optimieren, müsste es Datenträger auf die gleiche Art beschreiben: Alles hintereinander und erst wenn es das Ende erreicht, wieder von vorne in die durch's löschen inzwischen frei gewordenen Bereiche.

 

[Bigeagle]

Ich nutze auch noch 4k cluster mit ntfs gerade weil man dann potentiell die kompression einschalten kann falls mal wieder jemand beschließt riesige, gut komprimierbare dateien unkomprimiert auf die platte zu werfen. ARK z.b. aber auch savegames mancher spiele.
Selbst mit der schlechten kompression auf ntfs lohnt das imo in manchen fällen.
Dann noch die unmengen kleinstdateien ... am ende blähen sich da manche ordner um ein paar gb auf weil jede 5 byte datei nun 4 mal so viel platz braucht oder so.

Habe vor einiger Zeit mal USB Sticks mit exfat formatiert, Musik drauf kopiert und im Auto laufen lassen. Nach ein paar Monaten ging es dann mit Lesefehlern los.

BTRFS/ZFS unterstützung für autoradios wär doch was.
ansonsten sollte das dateisystem bei praktisch WORM (einmal voll machen, danach nur noch lesen und ab und an ergänzen) keine rolle spielen was datenfehler angeht. Das autoradio wird ja hoffentlich nicht für jeden lesezugriff metadaten aktualisieren (atime)

 

[wagga]

Etwas skurril, dass nicht alle Mainboard Hersteller betroffen sind.
Ich hab ein MSI, und auch ein Ami BIOS.

Oder der Hersteller war nicht in der Lage alle zu kaufen und zu testen?

Ergänzung (Gestern um 17:01)

50 Jahre nach der Entwicklung von FAT und immerhin 30 seit FAT32 scheint das immer noch das einzige Dateisystem zu sein, was wirklich alle Beteiligten halbwegs unfallfrei implementieren können.

Das ist traurig aber stimmt, blöd nur das FAT32 32 Bit ist und bei 3 GB Dateigröße Schluss ist.

 

[satis]

Thx Pete, das sich mal einer kümmert ^^

 

[mae]

Eigentlich sollte man AMI dafür druck machen.

Man? Wer? Die Kunden von AMI sind die Motherboardhersteller, und die interessiert es in erster Naeherung nicht, ob Rufus funktioniert. Da muessten die Kunden schon bei den Mainboardherstellern anfragen (und zwar in nennenswertem Ausmass), warum es bei ihnen nicht funktioniert. Und die machen dann Druck bei AMI.

Ergänzung (Gestern um 18:11)

was bringt einem f2fs auf einem stick, der möglichst interoperabel sein soll?

Aehnlich viel wie NTFS oder ExFAT.

 

[Tsu]

„X rechnet mit Y ab“ – wäre schön, wenn sich die Redaktion von solchen Unterschicht-Narrativen wieder entfernen würde.

 

[MaverickM]

Aehnlich viel wie NTFS oder ExFAT.

exFAT wird breit unterstützt, von allen Betriebssystemen (Bis mindestens Windows 7 zurück, ähnlich bei Linux und MacOS), selbst Endgeräten wie Fernsehern, Streaming Sticks, BD-Player, NAS etc. Selbst NTFS wird deutlich breiter unterstützt als F2FS.

 

[mae]

exFAT wird breit unterstützt, von allen Betriebssystemen (Bis mindestens Windows 7 zurück, ähnlich bei Linux und MacOS)[...] Selbst NTFS wird deutlich breiter unterstützt als F2FS.

Was exFAT betrifft, waere mir das neu, da Microsoft die Verbreitung mit ihren Patentanspruechen aktiv verhindert haben; jetzt nachgelesen, sie haben die 2019 in das OIN uebergefuehrt, aber der Schaden war angerichtet, jeder hatte sich ueber die Jahre gemerkt, dass man davon die Finger lassen sollte, wenn man nicht verklagt werden will wie bei VFAT. Mir ist bis jetzt kein exFAT-Filesystem untergekommen, und auf meiner Debian-Installation kann ich kein exFAT-Filesystem formattieren; immerhin sehe ich exfat-Kernel-Module, also mounten geht vielleicht. Oder auch nicht, wie die NTFS-Erfahrung lehrt.

NTFS sind mir schon untergekommen, und da sind in meinem System Treiber vorhanden, aber mir ist es mehrmals passiert, dass es beim Mounten geheissen hat, dass das NTFS nicht clean unmounted wurde und es daher nicht gemounted werden kann, oder nur read-only oder sowas.

Endergebnis: Die einzigen Filesysteme, die wirklich interoperabel sind, sind FAT32, FAT16, und ISO9660.

 

[mibbio]

exFAT wird breit unterstützt

Auch weil es in der Spezifikation von SDXC das offizielle-Dateisystem ist. Jedes Gerät mit entsprechendem Kartenslot muss praktisch exFAT unterstützen, wenn es voll kompatibel zum Standard sein will. Und SDXC-Karten werden entsprechend in der Regel exFAT-formatiert ausgeliefert. Der Umstand dürfte maßgeblich zur Verbreitung von exFAT beitragen.

 

[LT.Verleum]

War gerade letzte Woche bzgl. Sicherung (Windows) von kleinen und größeren Datenblöcken über einen extenen USB Stick bzw. externe SSD ein Thema für mich. Allgemein für kleine bis mittlere Dateiengößen 4K-16K Cluster und bei größeren Dateien 32K bis 64K Cluster um eine optimale Lese-und Schreibleistung zu erhalten. Je nach Umgebungs- und Kompatiblitätsanspruch (FAT32 oder NTFS u.a. ) geht das auch über die Kommandozeile z.B. Format (LW ): /FS:FAT32 /A:32K // (LW) durch den entsprechenden Laufwerksbuchstaben ersetzen ). Quasi wie in der Tuner-Szene um um am letzten bischen Performance zu drehen

 

[ThePlayer]

@0x8100 Ist es nicht.
Bei NTFS kannst du davon ausgehen, weniger oft korrupte Daten zu haben.
Habe vor einiger Zeit mal USB Sticks mit exfat formatiert, Musik drauf kopiert und im Auto laufen lassen. Nach ein paar Monaten ging es dann mit Lesefehlern los.
Wieder mit NTFS formatiert und seitdem keine Probleme mehr.

Wieso sollten bei 1x geschriebenen Daten Lesefehler nach Monaten entstehen? Und nicht sofort da sein. Ich gehe davon aus das Du den Stick mehrmals die Woche benutzt hast oder?

 

[Cool Master]

@Cool Master FAT32 kann nur unter 4GB große Datein umgehen.

Was für ein USB Installer/Stick doch locker ausreicht - vor allem für Windows.

exfat

Ja, aber auch hier gilt das kann nicht jedes System und wie gesagt für ein USB Stick sollte FAT32 locker ausreichen.

 

[0x8100]

Was für ein USB Installer/Stick doch locker ausreicht

nicht wenn man z.b. ventoy verwendet, wo die isos drauf liegen. inzwischen kann doch jedes gerät exfat, warum dann noch fat32 nehmen?

 

[AAS]

Oooh, so muss man es nicht selbst machen, nett, sehr nett.
Guter Hersteller :-)

Man kann auch einfach die Shift-Taste drücken

 

[basti2k]

Ich empfehle schon lange, ntfs vorzugsweise mit 16k Cluster zu formatieren, da es damit am effizientesten ist: wie hier dokumentiert

Außerdem kann dann keine Datenträgerkomprimierung aktiviert werden, die auch gerne Probleme verursacht.

Große Clustergrößen führen ggf. zu mehr Cluster Slack.
Bei SSDs reduziert es z.B. die interne Write-amplification wenn die Clustergröße genau der Speicherseitengröße gewählt wird. Dabei muss auch die Ausrichtung der Partition stimmen, denn dieses Problem hatte man mit WindowsXP und den Festplatten mit 4K Sektoren. Aber für diese Informationen muss man den internen Aufbau der SSD kennen (Speicherseitengröße, Blockgröße, etc.).

Und bloß wegen der NTFS Komprimierung, auf eine Clustergröße von 4KB zu verzichten, verstehe ich nicht ganz. Die Komprimierung muss man ja nicht nutzen

Seit Windows Vista lässt sich das Betriebssystem auch nur noch auf NTFS-Laufwerken installieren, da Microsoft intern NTFS-features verwendet (z.B. beim WinSxS-Verzeichnis und der Windows-Updateinstallation wird auf Hardlinks gesetzt).

 

[M@tze]

Sehr schön, seit 2024 bei AMI bekannt aber irgendwie hat sich dort niemand dazu berufen gefühlt, den auch mal zu patchen? Ob der jetzt bei der großen Mehrheit der User von Belang ist oder nicht, wie hier diskutiert wird, kann doch erstmal komplett egal sein, oder?

Etwas skurril, dass nicht alle Mainboard Hersteller betroffen sind.

Das steht da aber nicht?!? 🤷‍♂️

den AMI für UEFI-Firmware bereitstellt und der unter anderem auf Mainboards von Asus, Gigabyte und Intel zum Einsatz kommt.

Es wurden Hersteller als Beispiele aufgeführt, nicht eine Liste aller möglichen Kandidaten. 😉
Im originalen Artikel:

commonly used in UEFI firmware produced by the likes of Asus, Gigabyte, Dell, intel and so on

Ich sag ja nicht, dass der Bug nicht dumm ist, sondern empfehle einfach ntfs-16k und begründe es.

Also sagst Du doch, dass der Bug dumm ist, wegen doppelte Verneinung und so?! 😉

 

[mibbio]

Aber für diese Informationen muss man den internen Aufbau der SSD kennen (Speicherseitengröße, Blockgröße, etc.).

Wobei das bei einer SSD ohnehin nicht so ganz trivial ist. Denn dort interagiert das OS ja gar nicht direkt mit der physischen Organisation des Speichers, sondern mit einer virtuellen (also quasi vorgetäuschten) Speicherstruktur vom SSD-Controller. Unabhängig von der virtuellen Clustergröße kann der Controller es intern für den NAND-Speicher also potentiell komplett anders umorganisieren.