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

basti2k schrieb:
Große Clustergrößen führen ggf. zu mehr Cluster Slack.
Nicht nur ggfs.: Welche Datei Passt schon auf's Byte genau ich die Cluster?

Fausformel ist: Anzahl der Dateien geteilt durch die halbe Clustergröße = Verschnitt.

Also bei z. B. 10000 Dateien:
  • 4k Cluster = knapp 20 MB Verschnitt
  • 16k Cluster = knapp 80 MB Verschnitt
Wer kopiert sich schon viele Dateien auf einen so kleinen Stick, dass die 60 MB mehr einen Unterschied machen? - Ganz zu schweigen von den üblichen Größen interner Laufwerke.

basti2k schrieb:
Aber für diese Informationen muss man den internen Aufbau der SSD kennen (Speicherseitengröße, Blockgröße, etc.).
Das hatte ich verlinkt: Lesen musst du es schon selbst. :)

Das korrente Alignmet ist natürlich das wichtigste. Da hast du recht.

basti2k schrieb:
Und bloß wegen der NTFS Komprimierung, auf eine Clustergröße von 4KB zu verzichten, verstehe ich nicht ganz.
Es ist schneller: Sowohl bein drauf kopieren der großen ISOs (ich nutze Ventoy für Multiboot - hier meine Anleitung), als auch beim anschließenden booten.

basti2k schrieb:
Die Komprimierung muss man ja nicht nutzen ;)
Klar. Aber 16k Cluster schützen diesbzgl. auch vor wild gewordenen Optimierungstools und der eigenen Schusseligkeit (Erfahrung macht klug ;)).
 
SternburgExport schrieb:
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.
Wer so nen proprietären Abfall wie NTFS für ESP nutzt... sorry... Mitleid hält sich in Grenzen... Fehler tun weh... aber der liegt nicht allein an AMI.

Erstens... NTFS als ESP, macht doch keiner mit Hirn! Warum? Braucht man nicht! ESP ist Bootloader, der braucht keinen 4gb Support! Da ist FAT32 ausreichend, erprobt und Standard. NTFS also nur ein Feature, aber dadurch auch nicht zuverlässig! Damit ein Fehlervektor, den ein ITler kennt! Und den erst recht ein BOOTSTICK-Hersteller kennen sollte....

Zweitens:
Deshalb nehme ich auch keine Proprietärensachen... muss ich das, nehme ich als Quelle vielleicht nicht eine Stelle, die kontextabhängig das gar nicht bis kaum verwendet, wie ein BIOS-Hersteller! Eben weil beim BIOS-Hersteller FAT32 genutzt, erprobt ist und ausreicht, sind selbst wenn sie als Feature NTFS-Treiber anbieten, die wohl kaum am wahrscheinlichsten ohne Fehler? Bei nen NTFS Boot Feature, was irgenwelche WinAdminRookies verwenden, weil sie es aus MS Docs zu übernommen haben`? Die werden es vermutlich zu recht nciht nochmal machen!:evillol:

Sprich RUFUS-Devs wollen von ihrem eigenen Fehler ablenken... und ja, ist peinlich. Für beide. Aber AMI kann zu Recht sagen: Sorry... aber NTFS bei ESP nutzt halt kaum einer... wurde übersehen....
Aber nutzt Rufus fürs Dateisystem NTFS als Treiber einen BIOS Hersterle....

Sprich der GAU tritt nur auf, wenn zwei keine Ahnung haben. Und bei einem, dem Bioshersteller verstrehe ich es eher, weil wenig bis nicht relevant. Aber warum nutze ich dann als Quelle meines proprietären Treibers einen BIOS-Hersteller, der wenig bis nichts mit NTFS zu tun hat, weil kein Standard-Dateisystem als Bootloader?!?!? :evillol:

Sprich der voll geschissene Schuh, ja, der ist von AMI, aber RUFUS hat ihn angezogen. Peinlich! Aber eher peinlicher für RUFUS. Und die dürfen sich natürlich darüber aufregen. Aber NTFS, wie auch exFAT-Support, ist einfach ein BIOS-Feature. Deshalb nutzt man auch FAT32, wie hier viele richtig erkennen. Einfach weil es reicht und durch die breite Nutzung Bugs schnell auffallen.

Und ungesprochenes IT gestzt, keep it smal, keep it simpel. Niemand bracht 4gb Support im Bootloader. Gild natürlich nicht für die Dateipartion. Aber dann nehm ich Quellen die viel mit Dateipartionen, nicht aber Bootloader Pationen zu tun haben oder nicht? Und NTFS ist keine primäre Bootloader Partion. Bios ist aber zum Booten da, für viel mehr nicht.
 
Zuletzt bearbeitet:
lynx007 schrieb:
Erstens... NTFS als ESP, macht doch keiner mit Hirn! Warum? Braucht man nciht! ESP ist Bootloader, der braucht keinen 4gb Support!
Zumal die ESP in 99% der Fälle gar nicht groß genug ist, damit Dateigrößen > 4 GB relevant werden. Windows legt bei der Installation auf einem frischen Datenträger standardmäßig eine ESP mit wenigen 100 MB (glaube aktuell 300 MB) an und selbst bei den meisten Linux-Distributionen sind es default maximal 1 GB für die ESP. Da passen also gar keine Dateien drauf, für die die Beschränkungen von FAT32 eine Rolle spielen.
 
  • Gefällt mir
Reaktionen: lynx007
Wer kopiert sich schon viele Dateien auf einen so kleinen Stick

@ alle
Ich empfehle allgemein für das Übertragen von vielen kleinen Dateien (z.B. portable Apps oder Datenbanken) auf einen USB-Stick mittels einem Komprimierprogramm (z.B. mit .zip oder .7z) durchzuführen.

Dies kostet zwar etws Prozessor-Rechenleistung, aber die komprimierten Daten können später in großen Blöcken übertragen wesentlich schneller übertragen werden.

Komprimieren muss man da nichtmal.
Es reicht das Einpacken der Daten zu einem "großen Klumpen".
Ist also auch für schwächere Rechner gut nutzbar.
Und schneller ist es i.d.R. auch.
Probiert es mal!
 
Zuletzt bearbeitet:
Tanzmusikus schrieb:
Komprimieren muss man da nichtmal.
Es reicht das Einpacken der Daten zu einem "großen Klumpen".
Ist also auch für schwächere Rechner gut nutzbar.
Im Prinzip einfach mit Tar in einen "Container" zusammenfassen. Zumindest, wenn man Linux nutzt, denn unter Windows gibt es ab Werk kein Tar (kann .tar aber öffnen).
 
Ja, Container ist ein passender Begriff dafür.

Ventoy nutzt übrigens extFAT für seine Datenpartition ... und FAT16 für die Bootpartition.
 
Zuletzt bearbeitet:
0x8100 schrieb:
nicht wenn man z.b. ventoy verwendet, wo die isos drauf liegen.

Ja ok gibt immer Ausnahmen

0x8100 schrieb:
inzwischen kann doch jedes gerät exfat, warum dann noch fat32 nehmen?

Ja in 99,9% nutze ich auch exFat aber für BIOS Updates usw brauch man idR noch Fat32.
 
Tanzmusikus schrieb:
Ja, Container ist ein passender Begriff dafür.
Ein ISO ist übrigens auch nichts groß anderes, als ein Container mit vielen Dateien: Man kann es z. B. mit Xarchiver (und vermutlich auch den meisten anderen Pack-Programmen) öffnen und auch testen.

Btw: Das gleiche gilt übrigens auch für ePubs: Das sind praktisch ZIP-Archive mit anderer Dateiendung und angepassten MIME-Typ.

Tanzmusikus schrieb:
Ventoy nutzt übrigens extFAT für seine Datenpartition ... und FAT16 für die Bootpartition.
Letzteres geht auch gar nicht anders, da die nur 32 MiB groß ist:
  • FAT16 kann maximal 216 Cluster verwalten
  • FAT32 muss über 216 Cluster haben
216*512 Byte (die kleinsmögliche Clustergröße ist ein Sektor) = 32768 kiB = 32 MiB

Also selbst mit 512 Byte Cluster (was natürlich Quatsch wäre) sind 32 MiB einen Sektor zu wenig für FAT32.

Der Vollständigkeit halber (ich mag Zahlenspielereien ;)):

FAT12 kann maximal 212 Cluster verwalten, die max. 64k groß sein dürfen, kann also maximal 256 MiB groß sein. - FAT16 übrigens 4 GiB.
 
Zurück
Oben