Groups > ger.ct > #397197 > unrolled thread

FAT16 in 2019?

Started by	Michael Bode <m.g.bode@web.de>
First post	2019-04-24 18:05 +0200
Last post	2019-04-26 17:54 +0200
Articles	18 — 8 participants

Back to article view | Back to ger.ct

  FAT16 in 2019? Michael Bode <m.g.bode@web.de> - 2019-04-24 18:05 +0200
    Re: FAT16 in 2019? Ulf.Kutzner@web.de - 2019-04-24 09:08 -0700
      Re: FAT16 in 2019? Michael Bode <m.g.bode@web.de> - 2019-04-24 18:26 +0200
    Re: FAT16 in 2019? Hermann Riemann <nospam.ng@hermann-riemann.de> - 2019-04-24 19:03 +0200
      Re: FAT16 in 2019? Michael Bode <m.g.bode@web.de> - 2019-04-24 19:24 +0200
        Re: FAT16 in 2019? Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-04-24 21:29 +0200
          Re: FAT16 in 2019? Michael Bode <m.g.bode@web.de> - 2019-04-24 21:43 +0200
    Re: FAT16 in 2019? Stefan Reuther <stefan.news@arcor.de> - 2019-04-25 18:00 +0200
      Re: FAT16 in 2019? Michael Bode <m.g.bode@web.de> - 2019-04-25 19:24 +0200
        Re: FAT16 in 2019? Dr. Joachim Neudert <neudert@5sl.org> - 2019-04-25 17:56 +0000
          Re: FAT16 in 2019? Michael Bode <m.g.bode@web.de> - 2019-04-25 20:36 +0200
        Re: FAT16 in 2019? Stefan Reuther <stefan.news@arcor.de> - 2019-04-26 18:01 +0200
          Re: FAT16 in 2019? Michael Bode <m.g.bode@web.de> - 2019-04-26 22:10 +0200
            Re: FAT16 in 2019? Stefan Reuther <stefan.news@arcor.de> - 2019-04-27 11:36 +0200
      Re: FAT16 in 2019? Herwig AQSR <herwig.huener@t-online.de> - 2019-04-26 03:46 -0700
        Re: FAT16 in 2019? Michael Bode <m.g.bode@web.de> - 2019-04-26 12:53 +0200
        Re: FAT16 in 2019? Lars Gebauer <lars.gebauer@yahoo.de> - 2019-04-26 11:56 +0000
        Re: FAT16 in 2019? Stefan Reuther <stefan.news@arcor.de> - 2019-04-26 17:54 +0200

#397197 — FAT16 in 2019?

From	Michael Bode <m.g.bode@web.de>
Date	2019-04-24 18:05 +0200
Subject	FAT16 in 2019?
Message-ID	<gibfpcFcbpeU1@mid.individual.net>

Ich habe heute ne defekte HP VSA (Virtual Storage Appliance) repariert,
die nicht mehr booten wollte. Booten soll der Server ESXi von einer
µSD-Karte. Auf der war ne Partition geschrottet. Zum Glück die LOG
Partition, da war nichts wichtiges drin. Aber warum zum Geier nimmt man
für sowas FAT16 und nicht EXT3 o.ä, das ein bisschen robuster ist?

[toc] | [next] | [standalone]

#397198

From	Ulf.Kutzner@web.de
Date	2019-04-24 09:08 -0700
Message-ID	<5e42ec4e-7ede-4d87-8461-1e62714ac132@googlegroups.com>
In reply to	#397197

Am Mittwoch, 24. April 2019 18:05:01 UTC+2 schrieb Michael Bode:
> Ich habe heute ne defekte HP VSA (Virtual Storage Appliance) repariert,
> die nicht mehr booten wollte. Booten soll der Server ESXi von einer
> µSD-Karte. Auf der war ne Partition geschrottet. Zum Glück die LOG
> Partition, da war nichts wichtiges drin. Aber warum zum Geier nimmt man
> für sowas FAT16 und nicht EXT3 o.ä, das ein bisschen robuster ist?

Das Problem ist zwar 2019 aufgetreten, aber von wann stammt die
Konfiguration bzw. die Karte?

Gruß, ULF

[toc] | [prev] | [next] | [standalone]

#397200

From	Michael Bode <m.g.bode@web.de>
Date	2019-04-24 18:26 +0200
Message-ID	<gibh1nFckkgU1@mid.individual.net>
In reply to	#397198

Am 24.04.19 um 18:08 schrieb Ulf.Kutzner@web.de:
> Am Mittwoch, 24. April 2019 18:05:01 UTC+2 schrieb Michael Bode:
>> Ich habe heute ne defekte HP VSA (Virtual Storage Appliance) repariert,
>> die nicht mehr booten wollte. Booten soll der Server ESXi von einer
>> µSD-Karte. Auf der war ne Partition geschrottet. Zum Glück die LOG
>> Partition, da war nichts wichtiges drin. Aber warum zum Geier nimmt man
>> für sowas FAT16 und nicht EXT3 o.ä, das ein bisschen robuster ist?
> 
> Das Problem ist zwar 2019 aufgetreten, aber von wann stammt die
> Konfiguration bzw. die Karte?

Die ist sicher neuer als EXT4, von EXT3 ganz zu schweigen.

[toc] | [prev] | [next] | [standalone]

#397206

From	Hermann Riemann <nospam.ng@hermann-riemann.de>
Date	2019-04-24 19:03 +0200
Message-ID	<gibj6gFd1gfU1@mid.individual.net>
In reply to	#397197

Am 24.04.19 um 18:05 schrieb Michael Bode:

> Aber warum zum Geier nimmt man
> für sowas FAT16 und nicht EXT3 o.ä, das ein bisschen robuster ist?

M$ mag (oder mochte) kein ext*.

Hermann
    der beim Datentausch über USB zu windows Rechner im FAT* verwendete.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#397220

From	Michael Bode <m.g.bode@web.de>
Date	2019-04-24 19:24 +0200
Message-ID	<gibkf1Fdc80U1@mid.individual.net>
In reply to	#397206

Am 24.04.19 um 19:03 schrieb Hermann Riemann:
> Am 24.04.19 um 18:05 schrieb Michael Bode:
> 
>> Aber warum zum Geier nimmt man
>> für sowas FAT16 und nicht EXT3 o.ä, das ein bisschen robuster ist?
> 
> M$ mag (oder mochte) kein ext*.

Und das hat was mit einem Bootmedium für ESXi zu tun?

[toc] | [prev] | [next] | [standalone]

#397240

From	Hergen Lehmann <hlehmann.expires.5-11@snafu.de>
Date	2019-04-24 21:29 +0200
Message-ID	<f1q6pf-6nk.ln1@hergen.dyndns.org>
In reply to	#397220

Am 24.04.19 um 19:24 schrieb Michael Bode:

> Am 24.04.19 um 19:03 schrieb Hermann Riemann:
>> M$ mag (oder mochte) kein ext*.
> 
> Und das hat was mit einem Bootmedium für ESXi zu tun?

Die Servicetechniker, die das Bootmedium 
erstellen/aktualisieren/konfigurieren sollen, könnten eventuell Windows 
auf ihren PCs haben?

[toc] | [prev] | [next] | [standalone]

#397243

From	Michael Bode <m.g.bode@web.de>
Date	2019-04-24 21:43 +0200
Message-ID	<gibsifFf4bgU1@mid.individual.net>
In reply to	#397240

Am 24.04.19 um 21:29 schrieb Hergen Lehmann:
> Am 24.04.19 um 19:24 schrieb Michael Bode:
> 
>> Am 24.04.19 um 19:03 schrieb Hermann Riemann:
>>> M$ mag (oder mochte) kein ext*.
>>
>> Und das hat was mit einem Bootmedium für ESXi zu tun?
> 
> Die Servicetechniker, die das Bootmedium
> erstellen/aktualisieren/konfigurieren sollen, könnten eventuell Windows
> auf ihren PCs haben?

Und? Falls das unter Windows gemacht werden sollte, nimmt man halt
Rufus. Ich denke eher man lädt sich das ISO auf den Rechner, mountet es
per ILO am Server und bootet den Installer, der das System auf der
SD-Card installiert und konfiguriert.

[toc] | [prev] | [next] | [standalone]

#397306

From	Stefan Reuther <stefan.news@arcor.de>
Date	2019-04-25 18:00 +0200
Message-ID	<q9sskl.18c.1@stefan.msgid.phost.de>
In reply to	#397197

Am 24.04.2019 um 18:05 schrieb Michael Bode:
> Ich habe heute ne defekte HP VSA (Virtual Storage Appliance) repariert,
> die nicht mehr booten wollte. Booten soll der Server ESXi von einer
> µSD-Karte. Auf der war ne Partition geschrottet. Zum Glück die LOG
> Partition, da war nichts wichtiges drin. Aber warum zum Geier nimmt man
> für sowas FAT16 und nicht EXT3 o.ä, das ein bisschen robuster ist?

Weil FAT16 Größenordnungen weniger komplex ist. Und weil FAT16 das von
der SD-Card-Association für SD-Karten < 32 GB vorgesehene Dateisystem ist.

Und so unrobust ist FAT gar nicht, erst recht, wenn man es für einen
Zweck wie Logging benutzt: Cluster allokieren, vollschreiben, FAT
aktualisieren, Verzeichniseintrag aktualisieren. Kann nach jedem Schritt
unterbrochen werden, ohne das Filesystem ernsthaft inkonsistent zu
machen. YMMV, hängt natürlich von der konkreten Implementation ab.


  Stefan

[toc] | [prev] | [next] | [standalone]

#397308

From	Michael Bode <m.g.bode@web.de>
Date	2019-04-25 19:24 +0200
Message-ID	<gie8qbFc0jU1@mid.individual.net>
In reply to	#397306

Am 25.04.19 um 18:00 schrieb Stefan Reuther:
> Am 24.04.2019 um 18:05 schrieb Michael Bode:
>> Ich habe heute ne defekte HP VSA (Virtual Storage Appliance) repariert,
>> die nicht mehr booten wollte. Booten soll der Server ESXi von einer
>> µSD-Karte. Auf der war ne Partition geschrottet. Zum Glück die LOG
>> Partition, da war nichts wichtiges drin. Aber warum zum Geier nimmt man
>> für sowas FAT16 und nicht EXT3 o.ä, das ein bisschen robuster ist?
> 
> Weil FAT16 Größenordnungen weniger komplex ist. Und weil FAT16 das von
> der SD-Card-Association für SD-Karten < 32 GB vorgesehene Dateisystem ist.

Und wen juckt das? Ein Proliant DL380 ist ja keine Digicam.

> Und so unrobust ist FAT gar nicht, erst recht, wenn man es für einen
> Zweck wie Logging benutzt: Cluster allokieren, vollschreiben, FAT
> aktualisieren, Verzeichniseintrag aktualisieren. Kann nach jedem Schritt
> unterbrochen werden, ohne das Filesystem ernsthaft inkonsistent zu
> machen. YMMV, hängt natürlich von der konkreten Implementation ab.

Tja, soweit die Theorie. Die Praxis ist halt, dass die Kiste wegen
kaputter Partition nicht mehr booten konnte. Auskunft vom VMWare
Support: da kann man nix machen, das passiert halt mal. Gab schon Serien
wo das nach ein paar Monaten passiert ist.

[toc] | [prev] | [next] | [standalone]

#397309

From	Dr. Joachim Neudert <neudert@5sl.org>
Date	2019-04-25 17:56 +0000
Message-ID	<q9ssce$ke$1@news.albasani.net>
In reply to	#397308

Michael Bode <m.g.bode@web.de> wrote:
> Am 25.04.19 um 18:00 schrieb Stefan Reuther:



> 
> Und wen juckt das? Ein Proliant DL380 ist ja keine Digicam.
> 



> 
> Tja, soweit die Theorie. Die Praxis ist halt, dass die Kiste wegen
> kaputter Partition nicht mehr booten konnte. Auskunft vom VMWare
> Support: da kann man nix machen, das passiert halt mal. Gab schon Serien
> wo das nach ein paar Monaten passiert ist.
> 

Du bist doch auch schon lange genug im Geschäft. 

Zusammengefasst: Shit Happens. 

-- 
please forgive my iPhone typos -sent via Newstap

[toc] | [prev] | [next] | [standalone]

#397316

From	Michael Bode <m.g.bode@web.de>
Date	2019-04-25 20:36 +0200
Message-ID	<gied0gF17p0U1@mid.individual.net>
In reply to	#397309

Am 25.04.19 um 19:56 schrieb Dr. Joachim Neudert:

>> Tja, soweit die Theorie. Die Praxis ist halt, dass die Kiste wegen
>> kaputter Partition nicht mehr booten konnte. Auskunft vom VMWare
>> Support: da kann man nix machen, das passiert halt mal. Gab schon Serien
>> wo das nach ein paar Monaten passiert ist.
>>
> 
> Du bist doch auch schon lange genug im Geschäft. 
> 
> Zusammengefasst: Shit Happens. 

Deswegen ärgert es mich ja, dass das so fragil gemacht ist. Ich hab auch
an einem Embedded System gebaut, dass von CF-Karte bootet. Und wir haben
peinlich darauf geachtet, möglichst wenig auf die Karte zu schreiben,
nicht dass die Dinger in 10 Jahren schon kaputt gehen. Sicherheitshalber
haben wir noch ne Ersatzkarte beigelegt. Dass die Kunden die
verschludern, ist ne andere Sache. Auf die Idee sich ausgerechnet FAT
als Dateisystem auszusuchen, ist aber niemand gekommen.

Zum Vergleich:
https://elinux.org/images/archive/0/02/20150326011053%21Filesystem_Considerations_for_Embedded_Devices.pdf

[toc] | [prev] | [next] | [standalone]

#397421

From	Stefan Reuther <stefan.news@arcor.de>
Date	2019-04-26 18:01 +0200
Message-ID	<q9vh13.21c.1@stefan.msgid.phost.de>
In reply to	#397308

Am 25.04.2019 um 19:24 schrieb Michael Bode:
> Am 25.04.19 um 18:00 schrieb Stefan Reuther:
>> Am 24.04.2019 um 18:05 schrieb Michael Bode:
>>> Ich habe heute ne defekte HP VSA (Virtual Storage Appliance) repariert,
>>> die nicht mehr booten wollte. Booten soll der Server ESXi von einer
>>> µSD-Karte. Auf der war ne Partition geschrottet. Zum Glück die LOG
>>> Partition, da war nichts wichtiges drin. Aber warum zum Geier nimmt man
>>> für sowas FAT16 und nicht EXT3 o.ä, das ein bisschen robuster ist?
>>
>> Weil FAT16 Größenordnungen weniger komplex ist. Und weil FAT16 das von

(FAT16 -> FAT. In der 32-Bit-Welt sind sie schon angekommen.)

>> der SD-Card-Association für SD-Karten < 32 GB vorgesehene Dateisystem ist.
> 
> Und wen juckt das? Ein Proliant DL380 ist ja keine Digicam.

Steht halt im Standard, und Gerüchten zufolge gab es schon
Flashcontroller, die darauf optimiert haben, dass da erst eine FAT und
dann die Daten stehen.

>> Und so unrobust ist FAT gar nicht, erst recht, wenn man es für einen
>> Zweck wie Logging benutzt: Cluster allokieren, vollschreiben, FAT
>> aktualisieren, Verzeichniseintrag aktualisieren. Kann nach jedem Schritt
>> unterbrochen werden, ohne das Filesystem ernsthaft inkonsistent zu
>> machen. YMMV, hängt natürlich von der konkreten Implementation ab.
> 
> Tja, soweit die Theorie. Die Praxis ist halt, dass die Kiste wegen
> kaputter Partition nicht mehr booten konnte. Auskunft vom VMWare
> Support: da kann man nix machen, das passiert halt mal. Gab schon Serien
> wo das nach ein paar Monaten passiert ist.

Ich habe dennoch Zweifel, dass die Ursache im Dateisystem FAT zu suchen
ist. Jedes andere "normale" Dateisystem schreibt genauso viel. Bei ext3
eben Block allokieren, vollschreiben, inode aktualisieren, Block-Bitmap
aktualisieren (und das alles übers Journal).

Was heißt überhaupt "Partition kaputt"? Flashmedien sterben auch gerne
mal einfach so. FAT ist trivial zu reparieren, es fehlen dann eben
schlimmstenfalls ein paar Dateien.


  Stefan

[toc] | [prev] | [next] | [standalone]

#397439

From	Michael Bode <m.g.bode@web.de>
Date	2019-04-26 22:10 +0200
Message-ID	<gih6t1Fk1seU1@mid.individual.net>
In reply to	#397421

Am 26.04.19 um 18:01 schrieb Stefan Reuther:

> Was heißt überhaupt "Partition kaputt"? Flashmedien sterben auch gerne
> mal einfach so. FAT ist trivial zu reparieren, es fehlen dann eben
> schlimmstenfalls ein paar Dateien.

Die beste Fehlermeldung, die ich bekommen habe, (von gparted) war sowas
wie 'directory / has size 0'. Da hat sich nichts repariert. Die
Fehlermeldungen von VMWare hab ich hier nicht.

[toc] | [prev] | [next] | [standalone]

#397480

From	Stefan Reuther <stefan.news@arcor.de>
Date	2019-04-27 11:36 +0200
Message-ID	<qa1erp.4pg.1@stefan.msgid.phost.de>
In reply to	#397439

Am 26.04.2019 um 22:10 schrieb Michael Bode:
> Am 26.04.19 um 18:01 schrieb Stefan Reuther:
>> Was heißt überhaupt "Partition kaputt"? Flashmedien sterben auch gerne
>> mal einfach so. FAT ist trivial zu reparieren, es fehlen dann eben
>> schlimmstenfalls ein paar Dateien.
> 
> Die beste Fehlermeldung, die ich bekommen habe, (von gparted) war sowas
> wie 'directory / has size 0'. Da hat sich nichts repariert. Die
> Fehlermeldungen von VMWare hab ich hier nicht.

Wenn die Meldung von gparted kommt, hat's den Superblock zerlegt. Da
steht bei FAT16 die Größe des Wurzelverzeichnisses drin[1]. Da der
Superblock bei FAT im laufenden Betrieb nicht geschrieben wird, war's
wohl der Flashcontroller.

Mit etwas Gebastel bzw. einem fähigen fsck ist dieser eine Fehler
reparabel. Die Frage ist aber, was es noch zerlegt hat, und da fürchte
ich, hat auch die Umgebung dran glauben müssen (FAT, Wurzelverzeichnis
selbst, erste Dateien). Bei ext3 hätte es entsprechend die erste
Blockgruppe zerlegt.


  Stefan


[1] https://en.wikipedia.org/wiki/BIOS_parameter_block#FAT12_/_FAT16

[toc] | [prev] | [next] | [standalone]

#397371

From	Herwig AQSR <herwig.huener@t-online.de>
Date	2019-04-26 03:46 -0700
Message-ID	<9d3d748b-9821-4a08-9d1a-5ad050bd3336@googlegroups.com>
In reply to	#397306

2019-04-26 12:46:00 +0200

> ...

> Und so unrobust ist FAT gar nicht, erst recht, wenn man es für einen
> Zweck wie Logging benutzt: Cluster allokieren, vollschreiben, FAT
> aktualisieren, Verzeichniseintrag aktualisieren. Kann nach jedem Schritt
> unterbrochen werden, ohne das Filesystem ernsthaft inkonsistent zu
> machen. YMMV, hängt natürlich von der konkreten Implementation ab.

Und vom CopyRightKnüppel von M$? (Seit Trump
hat die generelle SündenBockFunktion von M$
arg gelitten.)

Herwig

[toc] | [prev] | [next] | [standalone]

#397374

From	Michael Bode <m.g.bode@web.de>
Date	2019-04-26 12:53 +0200
Message-ID	<gig68jFcv3fU1@mid.individual.net>
In reply to	#397371

Am 26.04.19 um 12:46 schrieb Herwig AQSR:
> 2019-04-26 12:46:00 +0200
> 
>> ...
> 
>> Und so unrobust ist FAT gar nicht, erst recht, wenn man es für einen
>> Zweck wie Logging benutzt: Cluster allokieren, vollschreiben, FAT
>> aktualisieren, Verzeichniseintrag aktualisieren. Kann nach jedem Schritt
>> unterbrochen werden, ohne das Filesystem ernsthaft inkonsistent zu
>> machen. YMMV, hängt natürlich von der konkreten Implementation ab.
> 
> Und vom CopyRightKnüppel von M$? (Seit Trump
> hat die generelle SündenBockFunktion von M$
> arg gelitten.)

So arm ist Dell nicht, dass sie nicht EMC erlauben könnten, VMWare zu
erlauben eine Lizenz zu kaufen.

[toc] | [prev] | [next] | [standalone]

#397379

From	Lars Gebauer <lars.gebauer@yahoo.de>
Date	2019-04-26 11:56 +0000
Message-ID	<slrnqc5sef.6j5.lars.gebauer@yenni.elke-albrecht.com>
In reply to	#397371

* Herwig AQSR:
> Und vom CopyRightKnüppel von M$? (Seit Trump
> hat die generelle SündenBockFunktion von M$
> arg gelitten.)

MS hat jetzt erstmal Apple als wertvollste Firma abgelöst.

[toc] | [prev] | [next] | [standalone]

#397422

From	Stefan Reuther <stefan.news@arcor.de>
Date	2019-04-26 17:54 +0200
Message-ID	<q9vgkl.ck.1@stefan.msgid.phost.de>
In reply to	#397371

Am 26.04.2019 um 12:46 schrieb Herwig AQSR:
> 2019-04-26 12:46:00 +0200
>> Und so unrobust ist FAT gar nicht, erst recht, wenn man es für einen
>> Zweck wie Logging benutzt: Cluster allokieren, vollschreiben, FAT
>> aktualisieren, Verzeichniseintrag aktualisieren. Kann nach jedem Schritt
>> unterbrochen werden, ohne das Filesystem ernsthaft inkonsistent zu
>> machen. YMMV, hängt natürlich von der konkreten Implementation ab.
> 
> Und vom CopyRightKnüppel von M$? (Seit Trump
> hat die generelle SündenBockFunktion von M$
> arg gelitten.)

Microsofts Schutzrechte beziehen sich auf Patente für die Koexistenz von
langen und kurzen Dateinamen. Man braucht für Logging keine langen
Dateinamen. Man kann das für kurze Dateinamen reservierte Feld einfach
mit Zufallswerten füllen, das braucht außer legacy-Software eh keiner.
Und da die Patente aus den 90ern sind, laufen sie bald aus.

Dürfte also kein Problem sein.


  Stefan

[toc] | [prev] | [standalone]

csiph-web

FAT16 in 2019?

Contents

#397197 — FAT16 in 2019?

#397198

#397200

#397206

#397220

#397240

#397243

#397306

#397308

#397309

#397316

#397421

#397439

#397480

#397371

#397374

#397379

#397422