<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hallo,
<blockquote cite="mid20060703184304.GA410@wolfden.dnsalias.net"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">ich plane auf meinem Zweitrechner demnächst Linux zu re-installieren, 
und frage mich welches Dateisystem ich für die Rootpartition nehmen 
soll. Ich bin mit ext3 bis jetzt gut gefahren, habe aber gelesen, dass 
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
erstmal vorneweg: Was soll alles auf der Root-Partition drauf sein? Willst
du dann andere Trees auf eine andere Platte machen?
  </pre>
</blockquote>
Nee, eigentlich nicht. Die Userverzeichnisse kommen auf ne
Extrapartition mit ext3, da gibt es keine Experimente, und der Rest
soll möglichst alles auf "/" liegen bleiben. Was ich also brauche ist
ein schnelles, einfach zu bedienendes FS, mit eingebauter Unterstützung
im Kernel. Habe mit dem Gedanken gespielt es nach den Erfahrungen auf
dem Desktop auf dem Laptop zu nehmen. <br>
<blockquote cite="mid20060703184304.GA410@wolfden.dnsalias.net"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">es *relativ* langsam ist und *relativ* viel Platz für das Journal 
benötigt.
      </pre>
    </blockquote>
  </blockquote>
</blockquote>
Es gibt Dateisystembenchmarks wie Sand am Meer. Ist mir auch schon
aufgefallen :-)<br>
<br>
Nach dem hier  <a
 href="http://www.debian-administration.org/articles/388">http://www.debian-administration.org/articles/388</a> 
hat aber ext3 ca. 6% für das Journal und das sind bei 300 GB schonmal
18 GB! Aber ok, natürlich wird die root-partition nicht soooo groß :-)
... selbst wenn ich mal die libs von GnuCash installieren muss. :-)
Nach besagtem Benschmaak wollte ich eigentlich XFS nehmen, aber ich
kann mich des Eindrucks nicht erwehren, dass ext3 von wirklich allen
hier auf der Liste bevorzugt wird. <br>
<br>
<blockquote type="cite">
  <pre wrap="">Und um gleich mal auf das gern geschätzte xfs draufzuhauen: Das
vernichtet bei der Recovery oft und gerne Dateien, die beim Crash zum
<span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>Lesen<span
 class="moz-txt-tag">_</span></span> geöffnet waren, sie enthalten anschließend nur noch Nullbytes.
Für mich ein KO-Argument, willst Du gerne noch ein debsums über /usr
machen?</pre>
</blockquote>
Gut, die Frage ist ja auch, wie sicher lassen sich Daten nach einem
Stromausfall wiederherstellen.... sehr wichtig. Aber sind die Daten bei
DIR kaputtgegangen, oder bei jemand anderem?<br>
<blockquote cite="mid20060703184304.GA410@wolfden.dnsalias.net"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">Nun, das hat ja Zeug für den nächsten Glaubenskrieg. Auch wenn ext3
wirklich nicht der Renner ist, besonders in der Disziplin "mkfs", so
kenne ich auch Thesen, daß man vermeintlich schnellere auch gut in die
Knie bekäme, würde man nur das Journalling auf die gleiche Qualität wie
bei ext3 einstellen.
    </pre>
  </blockquote>
  <pre wrap="">
Ich mache nicht so viel, was plattenintensiv ist, von daher ist es _mir_
nicht aufgefallen, daß ext3 so langsam sein soll.
  </pre>
</blockquote>
<br>
Mir gehts hauptsächlich ums booten. Und das mache ich ziemlich oft.... <br>
<blockquote cite="mid20060703184304.GA410@wolfden.dnsalias.net"
 type="cite">
  <pre wrap="">
Ich hatte auch mal überlegt, xfs einzusetzen. Bin dann aber doch zu ext3
gegangen, da ich für xfs damals keine Howtos gefunden habe, wie man
gelöschte Dateien wiederherstellen kann. (Jaja, ein rm an der falschen
Stelle, am besten noch mit -rf garniert...) Mit debugfs fahre ich da unter
ext2/3 ganz gut. Aber möglicherweise gibt es vergleichbare Tools (und
Howtos) mittlerweile auch für andere fs.
  </pre>
</blockquote>
Hmmm... das stürzt mich nicht in tiefe persönliche Abgründe, aber es
irritiert etwas. Wenn man bei Google eingibt "gelöschte Datei
wiederherstellen ext3" (oder so), steht überall drin, dass man von ext3
keine Daten wiederherstellen kann... <br>
<blockquote cite="mid20060703184304.GA410@wolfden.dnsalias.net"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">Partitionen mit anderen Dateisystem-Typen verschieben; für das
verbleibende / brauchst Du in aller Regel keine 100MB mehr; und
irgendwann kommt mal der Tag, wo man das im Regelfall nur noch read-only
    </pre>
  </blockquote>
  <pre wrap="">
Auch kann ich mich erinnern, daß zumindest unter Woody einige Programme
Config-Dateien unter /etc abgelegt hatten, die viele Megabyte verschlangen.
(/etc/gconf ist mir dahingehend sehr negativ aufgefallen. Da mußte ich
zwischenzeitlich wilde Softlinks machen, sonst liefen Updates teilweise
wegen Platzmangel nicht durch.) Ich glaube aber, in dieser Hinsicht hat sich
auch ein wenig was verbessert. Die Maintainer-Default-Einstellungen liegen
nun meist unter /usr, wenn der Admin entsprechende Dateien unter /etc
anlegt, werden die gelesen und dann halt noch das unter $HOME, falls
vorhanden.
  </pre>
  <blockquote type="cite">
    <pre wrap="">mounten muß. Dann ist die Performance-Frage auch nicht mehr wichtig.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Wenn das System nur lesend auf Dateien einer rw-gemounteten Partition
zugreift, geht da die Performance so in den Keller? Wird da außer
atime-Update noch was gemacht?

Auf einem anderen Rechner habe ich aus Bequemlichkeit alles in eine
Partition geworfen (außer swap natürlich). Ich fahre damit bisher auch nicht
schlechter, als mit dem Rechner, der viele Partitionen hat.</pre>
</blockquote>
Das wollte ich wissen! Also macht es doch keinen Unterschied ob man
sich viel Arbeit mit der Partitionierung macht, oder nicht?! Ich hab ne
laufende Kanotix-Installation auf Reiser4 und irgendwie kommt mir das
halt auch nicht schneller vor als das was ext3 so macht. Andererseits
sind die Benchmarks schon relativ eindeutig - zumindest bezogen auf
ext3. Aber vielleicht wird ja mit ext4 alles besser und schneller.... <br>
<br>
Grüßle, <br>
Frank<br>
</body>
</html>