robustes Filesystem?

Message

tazinblack · Post by **tazinblack** » Mon Mar 30, 2009 11:03 am

Hallo zusammen,

ich weiß dass das wieder einen Glaubenskrieg auslösen kann und bin mir auch bewusst, das dieses Thema schon des Öffteren angesprochen worden ist.
Deshalb poste ich hier im Diskussionsforum und die, die es trotzdem stört mögen doch bitte nachsichtig sein.

Da es mir gerade heute wieder ein Filesystem zerlegt hat stellt sich mir die Frage : Welches FS kann man den wirklich als robust ansehen. Dabei ist mir die Geschwindigkeit erst in zweiter hinsicht wichtig.

Heute war es mal wieder ein ReiserFS in der Version 3.6. Bedauerlicherweise konnte es reiserfsck auch nicht wieder fixen. Ich schick das ganze Raid nachher wohl zu Ontrack : "Eine Datensicherung ist ja nicht notwendig, da dort nur temporäre Daten liegen" (Hat sich inzwischen wohl geändert?!?).

Interessantereise sagt der Raidcontroler das alles i.O. ist, aber dennoch ist das FS korrupt.

Über die Jahre hinweg hab ich inzwischen auch schon einiges erlebt :

JFS unter Linux einmal (hab ich danach leider auf reiser umgestellt)
ReiserFS 3.6 schon mehrfach (verwende jetzt bevorzugt EXT3)
JFS unter AIX auch schon einmal (da dachte ich immer, das sei unkaputtbar)

Inzwischen sehe ich ja nur noch EXT3 unter Linux und JFS2 unter AIX als robust an. Mit XFS habe ich bisher keine Erfahrungen und die Tatsache das Ontrack das nicht in der Liste der wiederherstellungsfähigen FS drin hat (es sei denn das läuft unter sonstiges) denke ich mal ich versuchs gar nicht erst.
Erstaunlich finde ich auch, wie robust NTFS doch zu sein scheint. Zu mindest hab ich da noch nichts Schlimmeres erlebt.

Was ich auch interessant finde ist, das Ontrack bei der Ursachenhäufigkeit für Datenverlust immerhin 9% auf Korrupte Software bzw. Softwarefehler zurückführt (http://www.ontrack.de/datenverlust-ursachen/) und nur 56% auf Hardwaredefekts.

Jetzt frag ich einfach mal in die Runde, womit Ihr sonst schlechte und auch gute Erfahrungen gemacht habt.
Ist EXT3 wirklich besser oder ist das nur mein Eindruck? Mich ärgert ja da immer, wenn man dann mal den Server nach 300 Tagen neu startet dauert der Check doch recht lang bei großen Platten/Raids. Doch wenns hilft, warum nicht.
Wie gesagt, Performance ist zweitrangig. Wenns zu langsam ist häng ich lieber mehr Platten rein.

69719 · Post by **69719** » Mon Mar 30, 2009 11:31 am

Ich hab immer auf ext3 mit sync option gesetzt und es hat mich nicht verlassen. Mitlerweile setzte ich auch ext4 ein und es hat mir noch keinerlei Probleme beschehrt.

Max Steel · Post by **Max Steel** » Mon Mar 30, 2009 2:16 pm

Ich setze auch vermehrt auf ext3 da ich damit bisher noch keine Probleme gehabt habe.
Die Systemstarts können sich durch die Checks störend in die Länge ziehen, vorallem wenn mans eilig hat, und vorallem wenn die Platte voll ist, oder fast voll (so 70-80%)
Aber ansonsten ist das ein zufriedenstellendes FS.

Reiser setze ich vorallem auf Partitionen mit vielen kleineren Dateien ein, zumindest scheint es mir hier sehr robust einsetzbar, vorallem der portage-tree und var sind bei mir damit am laufen.

Post by **toralf** » Mon Mar 30, 2009 2:47 pm

ich hatte ReiserFS auch mal für den portage Baum, bin allerdings nach 2maligen Crash zu ext3 gewechselt und seitdem zufrieden. Nervig ist der fsck, aber mit tune2fs habe ich die Defaultwerte auf 6 Monate / 100 mounts gesetzt - das läuft seitdem seit ca. 2 Jahren einfach so ohne Probleme.

schachti · Post by **schachti** » Mon Mar 30, 2009 4:52 pm

Wirklich robust ist meiner persönlichen Erfahrung nach vor allem ext3 mit mount-Option data=journal.

Mr. Anderson · Post by **Mr. Anderson** » Mon Mar 30, 2009 4:55 pm

Mit reiserfs3 habe ich in seltenen Fällen auch Probleme. Allerdings hab ich auch nichts anderes im Einsatz. Im Portage Tree läuft das absolut rund. Aber wenn ich z. B. mehrere hunderttausend kleine Dateien auf einmal lösche (z. B. ccache), zerlegt es mir das Dateisystem manchmal. Hat sich immer wieder in Ordnung bringen lassen mit reiserfsck, aber vertrauenerweckend ist das nicht. Ob das nun mit anderen Dateisystemen nicht passiert wäre, weiß ich nicht. Möglicherweise ist auch irgendwas von der Hardware nicht in Ordnung oder irgendein anderer Treiber ist fehlerhaft oder sonstwas. Dass jfs auch nicht besser funktionieren soll, wundert mich etwas. Das hätte ich als erste Alternative versucht.

SvenFischer · Post by **SvenFischer** » Mon Mar 30, 2009 4:59 pm

Wiederherstellung:

app-admin/testdisk

Wenn Du (teilweise) erfolgreich warst, dann laß es uns wissen!

mrsteven · Post by **mrsteven** » Mon Mar 30, 2009 5:50 pm

ext3 mit data=journal hat sich bei mir ebenfalls als sehr zuverlässig erwiesen - trotz einiger Hardresets. Die regelmäßigen Dateisystemchecks kann man mit tune2fs abschalten, dann sollte man aber sicherheitshalber hin und wieder mit shutdown -rF now diese Prüfungen erzwingen. Das hat zwar bei mir noch nie irgendwelche Fehler ausgespuckt, aber man weiß ja nie ob sich nicht doch einmal ein Bug irgendwo einschleicht oder die Platten eine Macke haben.

Anarcho · Post by **Anarcho** » Mon Mar 30, 2009 6:58 pm

ext3++

musv · Post by **musv** » Mon Mar 30, 2009 7:32 pm

Ok, jetzt fall ich mal aus der Reihe:
Ich verwende seit ca. 3 Jahren für root ausschließlich Reiser4. Trotz unzähliger Systemabstürze aufgrund von Temperaturproblemen und sonstigen Dummheiten meinerseits hatte ich nie einen Datenverlust damit. Ein oder zwei Mal konnte ich es nicht mehr mounten nach einem Crash. Ein fsck.reiser4 hat das wieder hingebogen. Nach meinen eigenen Erfahrungen hat Reiser4 bisher die meisten Crashs ohne Probleme einfach so weggesteckt, meistens war nicht mal ein fsck notwendig (FS-Check dauert übrigens elende lang bei Reiser4).

Im Einsatz hab ich noch JFS, was aber unter bestimmten Voraussetzungen ziemlich fragmentiert bei mir. Das äußert sich dadurch, dass bei manchen Dateien die Platte rotiert, als ob da Hunderte von GB durch die Gegend geschaufelt werden. Verschieb ich dann die betroffenen Dateien auf ein anderes Dateisystem und schreib die wieder zurück, geht's wieder normal. Einen Datenverlust hatte ich bisher mit JFS noch nicht, begeistert von JFS bin ich jedoch auch nicht sonderlich.

Und ansonsten läuft hier noch XFS. Das war bisher das einzige FS, bei dem ich einen Datenverlust hatte. Komischerweise ohne Crash. Ich hatte damals zum allerersten Mal eine xfs-Partition angelegt, die Daten draufgespielt. Rechner neu gestartet. Da kam dann 'ne Fehlermeldung, dass die Partition nicht mehr gemountet werden konnte. xfs_repair und xfs_dump weigerten sich. Tja, und da waren 20 GB Daten weg. Waren zum Glück keine wichtigen Daten.

Für Production-Server und Raid würde ich wahrscheinlich auch eher ext3 vorziehen.

Reiser3.6 würde ich aufgrund der starken Fragmentierung nicht mehr verwenden. Ich hatte das mal ein paar Jahre in Benutzung. Datenverlust hatte ich nie, aber beim damals täglichen Portage-Update wurde Reiser3.6 nach ca. 6 Monaten fast unbenutzbar langsam.

mv · Post by mv » Mon Mar 30, 2009 8:58 pm

Vom Konzept her sind ext4 und Reiser4 die einzigen Kandidaten, wobei beide Schwächen haben (ext4 hat keine "atomic"-Operationen, Reiser4 hat keine Journal-Checksums und wohl die Schwäche von Reiser3 geerbt, nur die neuen Metadaten ins Journal zu schreiben und nicht den ganzen Block mit den Metadaten). Dadurch sind auch diese beiden vom Konzept her nicht als ganz robust anzusehen, wobei die Schwächen von ext4 wohl am unwahrscheinlichsten zutage treten.

ext3 würde ich höchstens mit der Kneifzange (data=journal,barrier=1) anfassen. Es ist mir vollkommen schleierhaft, weshalb diese Optionen erst bei ext4 der Default sind (data=alloc_on_commit bei ext4 ist das korrektere Konzept, aber das ist derzeit erst per Patch in Kernel 2.6.29 und richtig erst in 2.6.30 verfügbar - sobald möglich, würde ich darauf umstellen). Ohne Journal-Checksumme ist ext3 bei Crashes immer problematisch (auch wenn sich das nicht immer auswirkt und in den meisten Fällen nicht tragisch).

Von der Implementierung her habe ich mit Reiser4 keine Erfahrung, würde es dem Hörensagen nach aber keineswegs als ausgereift bezeichnen. Und ob man ein Filesystem will, das wohl nie in den Kernel kommt und immer eingepatched werden muss?

Die Ext4-Implementierung scheint ziemlich ausgereift zu sein - ich fahre es derzeit ausschließlich (von vereinzelten ext2-Boot-Partitionen abgesehen) und hatte noch nie damit Probleme.

Was ich empfehlen würde: ext4, wobei man vielleicht nicht alle ext4-Features nutzen sollte, wenn man sehr vorsichtig sein will (also i.W. mit einem ext3-formatierten Filesystem, wobei die neue Inode-Size=256 und das zugehörige extra_isize-Feature wohl kaum schaden können, und wie gesagt: Ich zumindest hatte auch mit den anderen Features noch keine Probleme).

tazinblack · Post by **tazinblack** » Tue Mar 31, 2009 8:46 am

SvenFischer wrote:Wiederherstellung:

app-admin/testdisk

Wenn Du (teilweise) erfolgreich warst, dann laß es uns wissen!

Erst mal danke für die vielen Tipps. Ich hätte die Platten gern getestet mit testdisk, hab sie aber inzwischen eingeschickt.

Anarcho · Post by **Anarcho** » Tue Mar 31, 2009 9:01 am

tazinblack wrote:
SvenFischer wrote:Wiederherstellung:

app-admin/testdisk

Wenn Du (teilweise) erfolgreich warst, dann laß es uns wissen!
Erst mal danke für die vielen Tipps. Ich hätte die Platten gern getestet mit testdisk, hab sie aber inzwischen eingeschickt.

Testdisk ist sowieso hauptsächlich dafür da Partitionstabellen wiederherzustellten (was eine wirklich tolle sache ist!).

avx · Post by **avx** » Tue Mar 31, 2009 9:25 pm

Bei mir hat XFS bis jetzt alles überlebt, was ihm angetan wurde. Egal ob Kernel-Crash(kein syncen via SysRQ möglich gewesen) oder auch der eine oder andere Stromausfall, wobei es ein wenig Datenverlust gab(mitten im Schreibvorgang), aber das FS an sich war stehts konsitent oder ohne Probleme reparierbar.

JFS und Reiser4 haben mich schon einige Male verlassen, Reiser3.(5,6) noch nie. BTRFS ist mir an einem Bug gestorben, der ist mittlerweile aber gefixt und abseits von Linux liessen mich auf UFS und ZFS bisher noch nie im Stich.

longint · Post by **longint** » Fri Apr 24, 2009 8:00 pm

Ich schwöre auf Reiser(3)FS, da hatte ich im Gegensatz zu ext2 früher noch nie einen Datenverlust. In ganz hartknäckigen Fällen baut man eben den Baum neu, dauert dann evtl. ein paar Stunden aber die Daten sind sicher wieder da. Mit Reiser4 habe ich keine Erfahrung.

mv · Post by mv » Sat Apr 25, 2009 9:44 am

longint wrote:Ich schwöre auf Reiser(3)FS, da hatte ich im Gegensatz zu ext2 früher noch nie einen Datenverlust.

So Meldungen in der Art "ich hatte noch nie Probleme damit" sind ziemlich sinnfrei, weil das ja auch nur bedeuten kann, dass Murphy noch nicht zugeschlagen hat.

Das Journaling von Reiser3 (und m.W. auch von Reiser4) ist buggy: Es werden nur die Daten im Journal gespeichert, die geändert werden sollen, nicht der gesamte neue Block, der geschrieben werden soll. Das verbessert zwar die Performance, aber wenn beim Schreiben des betreffenden Blocks der Rechner ausfällt, ist der ganze Block kaputt. Dadurch werden typischerweise auch Konsistenz des Filesystems oder Daten von Dateien beschädigt, die gar nicht offen waren.
Und so gut mir intelligente Datenstrukturen (wie die dancing trees bei Reiser4) gefallen: Für ein Filesystem eignen sich solche komplexe Datenstrukturen leider nicht, weil sie zu sensibel für Hardwareprobleme sind. Es passiert halt nicht so selten, dass einmal ein Block auf einer Platte nicht mehr gelesen werden kann oder wegen einer Stromschwankung falsch geschrieben wird - bei komplexen Datenstrukturen kann dies einen Verlust eines sehr großen Teils der Daten bedeuten und vielleicht sogar Totalausfall.

In ganz hartknäckigen Fällen baut man eben den Baum neu, dauert dann evtl. ein paar Stunden aber die Daten sind sicher wieder da.

Falcsh. Neubauen des Baums ist ein wildes Glücksspiel. Es ist ein bekannter Bug von Reiser3, dass das sogar i.d.R. schief geht, falls man Daten auf der Partition gespeichert hatte, die für reiserfs wie Metadaten aussehen; beispielsweise durch Spiegeln einer anderen reiserfs-Partition in eine Datei und anschließendes Neubauen des Baum hat man mit ziemlicher Sicherheit das gesamte Filesystem geschrottet.

Und nicht zu vergessen: Reiser3 wird praktisch nicht mehr gewartet. Das ist zwar kein technischer Grund, der gegen die Benutzung spricht, aber doch ein wichtiger.

tazinblack · Post by **tazinblack** » Sat Apr 25, 2009 10:10 am

mv wrote:
In ganz hartknäckigen Fällen baut man eben den Baum neu, dauert dann evtl. ein paar Stunden aber die Daten sind sicher wieder da.
Falsch. Neubauen des Baums ist ein wildes Glücksspiel. Es ist ein bekannter Bug von Reiser3, dass das sogar i.d.R. schief geht, falls man Daten auf der Partition gespeichert hatte, die für reiserfs wie Metadaten aussehen; beispielsweise durch Spiegeln einer anderen reiserfs-Partition in eine Datei und anschließendes Neubauen des Baum hat man mit ziemlicher Sicherheit das gesamte Filesystem geschrottet.

Und nicht zu vergessen: Reiser3 wird praktisch nicht mehr gewartet. Das ist zwar kein technischer Grund, der gegen die Benutzung spricht, aber doch ein wichtiger.

Das kann ich auch bestätigen. Dauert Stunden und macht alles nur noch schlimmer.
Außerdem kann ich mich nicht mit dem Gedanken anfreunden, dass der Author meines FS im Knast sitzt.

Ich bin ja mal gespannt, wie denn BTRFS wird, wenns denn mal stable ist. Was ich aber jetzt schon nicht so toll finde an btrfs ist, dass da wohl Oracle dahinter steht.

Irgendwie fehlt mir seit jeher schon ein adäquates Pendant zu JFS2 auf AIX unter Linux.
Ich finde es einfach nicht mehr Zeitgemäß wie unkomfortabel die meisten FS unter Linux in Verbindung mit LVM sind.

mv · Post by mv » Sat Apr 25, 2009 12:17 pm

tazinblack wrote:
mv wrote:Falsch.

[OT]Dass Du das als vermeintlichen Flüchtigkeitsfehler korrigiert hast, zeigt, dass Du keine Erfahrung im Usenet hast. Bekanntlich schreibt sich flsach doch nicht "richtig".[/OT]

Außerdem kann ich mich nicht mit dem Gedanken anfreunden, dass der Author meines FS im Knast sitzt.

Um bei dem praktischen Aspekt davon zu bleiben: Dies meinte ich nicht, als ich sagte, dass Reiser3 praktisch nicht mehr gewartet wird. Es wurde auch schon lange nicht mehr gewartet, bevor diese Geschichte passiert ist. Und für Reiser4 gilt meine Bemerkung nicht: Da gibt es m.W. durchaus aktive Entwicklung. Aber wohl leider keine Chance, dass es jemals in den offiziellen Kernel kommt, was aber ebenfalls nichts mit obiger Sache zu tun hat, sondern mit einem mir unverständlichen Gebärden der Kernel-Maintainer - aber das brauchen wir nicht nochmals alles durchzukauen.

tazinblack · Post by **tazinblack** » Sun Apr 26, 2009 1:52 pm

mv wrote:
tazinblack wrote:
mv wrote:Falsch.
[OT]Dass Du das als vermeintlichen Flüchtigkeitsfehler korrigiert hast, zeigt, dass Du keine Erfahrung im Usenet hast. Bekanntlich schreibt sich flsach doch nicht "richtig".[/OT]

Tja, Irren ist menschlich. Bis ins Usenet bin ich bisher nur selten vorgedrungen. Ist irgendwie nicht meine Welt, sonst wär ich da wohl öfter.

Außerdem kann ich mich nicht mit dem Gedanken anfreunden, dass der Author meines FS im Knast sitzt.
Um bei dem praktischen Aspekt davon zu bleiben: Dies meinte ich nicht, als ich sagte, dass Reiser3 praktisch nicht mehr gewartet wird. Es wurde auch schon lange nicht mehr gewartet, bevor diese Geschichte passiert ist. Und für Reiser4 gilt meine Bemerkung nicht: Da gibt es m.W. durchaus aktive Entwicklung. Aber wohl leider keine Chance, dass es jemals in den offiziellen Kernel kommt, was aber ebenfalls nichts mit obiger Sache zu tun hat, sondern mit einem mir unverständlichen Gebärden der Kernel-Maintainer - aber das brauchen wir nicht nochmals alles durchzukauen.

Das hab ich auch so nicht gemeint. Ich finds bloß nicht so toll Software einzusetzen, deren Erfinder im Knast sitzt.

kernelOfTruth · Post by **kernelOfTruth** » Mon Apr 27, 2009 8:39 pm

longint wrote:Ich schwöre auf Reiser(3)FS, da hatte ich im Gegensatz zu ext2 früher noch nie einen Datenverlust. In ganz hartknäckigen Fällen baut man eben den Baum neu, dauert dann evtl. ein paar Stunden aber die Daten sind sicher wieder da. Mit

++

reiserfs (v3.6) ist IMO zur Zeit wirklich das stabilste Dateisystem wenn euch eure Daten lieb sind

wie ich im englischen Teil schon ein paarmal gepostet hab: ich hatte mit reiserfs bis jetzt noch keinerlei Probleme und Datenverluste im Gegensatz zu den anderen Dateisystemen:

* JFS: Datenverlust (fsck hat glaub ich sogar Dateien gelöscht), Probleme mit Dateinamen, ...
* XFS: das übliche zero-file schreiben nach einem Crash -> leere Dateien, Datenverlust, starke Beanspruchung der Festplatte ...
* ext3/ext4: Datenverlust, totale Korrumpierung des Dateisystems/Baums, öfters lost+found dateien ...

# reiser4: ab und an vollständiger Datenverlust allerdings nur auf der Systemplatte und das mit/ohne Kompression das ist aber schon mindestens 1-1.5 jahre her und die gröbsten Fehler behoben (kudos an Edward Shishkin)
reiser4 scheint irgendwie leichte probleme mit dem einsatz auf der Systempartition zu haben auf den Datenpartitionen macht es allerdings einen noch stabileren Eindruck als reiserfs (ebenfalls noch kein Datenverlust)

musv · Post by **musv** » Tue Apr 28, 2009 1:55 pm

kernelOfTruth wrote:* XFS: das übliche zero-file schreiben nach einem Crash -> leere Dateien, Datenverlust, starke Beanspruchung der Festplatte ...

Komisch, bei mir beansprucht gerade xfs die Platte sehr wenig. Aber gut, ich verwende xfs auch nur für die Partition mit den Multimediadaten.

kernelOfTruth wrote:# reiser4: ab und an vollständiger Datenverlust allerdings nur auf der Systemplatte und das mit/ohne Kompression das ist aber schon mindestens 1-1.5 jahre her und die gröbsten Fehler behoben (kudos an Edward Shishkin)
reiser4 scheint irgendwie leichte probleme mit dem einsatz auf der Systempartition zu haben auf den Datenpartitionen macht es allerdings einen noch stabileren Eindruck als reiserfs (ebenfalls noch kein Datenverlust)

Ich verwende Reiser4 ausschließlich für die Systempartition, weil ich gerade mit der Homepartition nur schlechte Erfahrungen gemacht hab:

1. KDE3:
Weiß nicht, ob das inzwischen behoben wurde. Aber diverse KDE-Anwendungen synchronisieren ständig irgendwas. Bei Reiser4 äußert sich das dann in übermäßigen Plattenzugriff. Konkretes Beispiel: Quanta - Wenn man da einen Tab mit einer Datei öffnet oder schließt, kann man bei Reiser4 direkt feststellen, dass dabei irgendwas geschrieben wird, weil genau bei diesem Vorgang das Quanta irgendwie immer leicht gestockt hat. Ein flüssiges Arbeiten war dadurch einfach nicht möglich. Auf meinem Uralt-Notebook hab ich keine separate Home-Partition. Da hab ich das KDE-Problem gelöst, indem ich beim Booten das ~/.kde-Verzeichnis sämtlicher Nutzer in ein tmpfs verschieb. Nur so kann ich damit flüssig arbeiten. Und nach meinen bisherigen Erfahrungen tritt das ausschließlich mit Reiser4 auf.

2. P2P
Egal ob Azureus oder Direct Connect oder aMule. Wenn die Datenpartition auf Reiser4 liegt, kann man die P2P-Anwendungen locker als Festplatten-Stresstest verwenden.

Dagegen hatte ich mit der Systempartition unter Reiser4 wirklich noch nie Probleme.

Ach ja, und wie mv schon gemeint hat:

mv wrote:So Meldungen in der Art "ich hatte noch nie Probleme damit" sind ziemlich sinnfrei, weil das ja auch nur bedeuten kann, dass Murphy noch nicht zugeschlagen hat.

JoHo42 · Post by **JoHo42** » Tue Aug 11, 2009 6:37 am

Hi Leute,

ich habe bei mir einen kleinen Rechner stehen, der 24 Stunden laeuft.
Dieser hat ein Gentoo auf einer 2 GB Compact Flashkarte, dient nur als
Backup File Server.

Wenn bei mir der Strom ausfaellt kann es ein das ich erst eine Tastatur
anschiessen muss und einen fsck machen muss, damit der wieder startet.

Welches Filessystem ist bei Spannungsausfall das bester?
Es kann ruhig mit Fehlern starten, wenn ich mal das System mit openssh
bearbeiten kann.
Ach ja USV kommt nicht in Frage, da fuer so ein bischen Hobby zu teuer.

Gruss Joerg

schachti · Post by **schachti** » Tue Aug 11, 2009 7:18 pm

JoHo42 wrote:Welches Filessystem ist bei Spannungsausfall das bester?

Meiner Meinung nach ext3, gemountet mit der Option data=journal.

think4urs11 · Post by **think4urs11** » Tue Aug 11, 2009 8:32 pm

JoHo42 wrote:Dieser hat ein Gentoo auf einer 2 GB Compact Flashkarte, dient nur als
Backup File Server.

Warum nicht einfach read-only booten analog zum CD-Boot?

JoHo42 · Post by **JoHo42** » Wed Aug 12, 2009 5:59 am

Hi Think4UrS11,

read-only waere eine moeglichkeit.
Allerdings habe ich hier noch das Problem, das ich da eine kleine Datenbank
habe die ich ganz gerne beschreiben moechte.
Auch ein paar Log Files will ich noch mit nehmen koennen.
Also eigentlich sollte das /var Verzeichnis weiter beschreibbar sein.

Kann ich einfach alles Readonly mounten und nur das /var Verzeichnis
read write geht das wuerde das was bringen oder bekomme ich dann immer noch
Probleme beim booten?

Gruss Joerg