<div>Hallo,</div><div><br></div><div>ich kann mich Peer nur anschließen.</div><div>Auch wenn ich über den ersten Kommentar zu reiserfs lachen musste, es ist und bleibt Teufelszeug.</div><div><br></div><div>Ich hab genau die gleichen Probleme mit reiserfs gehabt.</div>
<div>Schwarze Löcher, ganze Teile von Verzeichnisbäumen sind  still und heimlich für immer verschwunden</div><div>obwohl alle check tools erfolg meldeten und versicherten: alles ok, wir können wieder durchstarten.</div><div>
Gleiches ist mir auch mit der Vergrößerung passiert unter reiserfs.</div><div><br></div><div>Mit ext3 und mit XFS hatte ich nie solche Probleme, weder Datenverlust noch sonst wie</div><div>seltsames Verhalten.</div><div>Auch nicht nach  Onlinevergrößerung oder Ausfällen wie z.b. Stromausfall während dem Betrieb.</div>
<div><br></div><div>Wobei ich anmerken möchte, dass ich was die Performance angeht die Erfahrung machte</div><div>dass xfs das schnellere Filesystem ist aus mehrerer Hinsicht.</div><div>Dafür muss man allerdings zugestehen es geht mehr an den CPU-Speck.</div>
<div><br></div><div>Generell ist es bei konkurrierendem Zugriff und bei großen Dateien schneller.</div><div>Ich hatte früher ( nach den schlechten Erfahrungen mit reiserfs)</div><div>bei ca. 200 Maschinen ext3 im Einsatz. Zufrieden war ich nie so recht,</div>
<div>da ich schnelleres gewohnt war von seiten FreeBSD mit UFS/UFS2.</div><div>Ich hab dann XFS ausgetestet und seit dem setze ich es für alles ein.</div><div>Fileserver, FTPServer, Mailserver, Webserver, Datenbankserver, Firewalls ( wenn den mit linux) etc.</div>
<div><br></div><div>Auch beim Backup z.B. mit dump ( resp xfs_dump) ist xfs schneller. mit ext3: 30 Minuten, xfs: 15Minuten</div><div>(ein vergleich auf ein und dem selben System, also wirklich das gleiche System, mit gleicher Partitionierung und gleichen Daten</div>
<div>im laufenden Betrieb - wie auch sonst? :D)</div><div><br></div><div>Meiner Erfahrung nach bringt es ca 10-20% Performance auf Kosten von etwas höherer CPU-Last.</div><div>Bei vielen kleinen Dateien ist XFS einen Tick langsamer, allerdings nicht viel, was sich durch ein  besseres Verhalten bei komkurrierendem Zugriff</div>
<div>auszeichnet. Auch die On-Disk Datenmenge ist weniger als bei Ext3 ( sprich die Metadaten scheinen weniger oder besser verwaltet zu sein.</div><div>Wenn kein ext3 verwendet wird sind die Buffers fast immer null, dafür sind die chaches stark benutzt.</div>
<div><br></div><div><br></div><div>Fazit: Stabil sind beide Ext3 und XFS, auch nach einer Onlinevergrößterung.</div><div>Und das sowohl in virtuellem Umfeld ( ESX/XEN/KVM) als auch auf echter Hardware.</div><div>Mit XFS erspart man sich die meisten Filesystemchecks.</div>
<div>Nur das ziehen vom SATA-Stecker und ein Stromausfall führten bei mir bsiher zu einem unweigerlich notwendigen</div><div>xfs_check und xfs_repair. </div><div><br></div>von tunefs -i -&gt; von wegen kein Filesystemcheck .....grrrrr.....gar nicht gut, da hat der Kollege Pröpper recht,<div>
besser nicht, Ausfälle kommen unverhofft und meist genau einen Tag oder kurz bevor der Filesytemcheck gemacht werden sollte. :D</div><div>Murphy&#39;s law.</div><div><br></div><div>just my 20 ct. and my eperiences ;-)</div>
<div><br></div><div>have fun</div><div><br></div><div>michael<br><br><div class="gmail_quote">Am 11. Juli 2011 21:36 schrieb &quot;Winfried Büchert&quot; <span dir="ltr">&lt;<a href="mailto:winfried.buechert@gmx.de">winfried.buechert@gmx.de</a>&gt;</span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hallo Admins,<br>
ich möchte virtuelle Linux Systeme aufsetzen, ohne LVM aber trotzdem mit der Möglichkeit die Dateisysteme (ausser &quot;/&quot; ) online zu vergrössern.<br>
Das ganze soll selbstverständlich wie gewohnt langzeitstabil laufen.<br>
<br>
Dieses funktioniert unter SLES11 SP1 :<br>
- Einrichten der Disk ohne Partitionstabelle, dann muss ich die Partitions-<br>
  tabelle nachher nicht verändern.<br>
- Vergrössern der Disk in VMware<br>
- unter Linux: rescan-scsi-bus.sh --forcerescan (ggf. noch SCSI ID mitgeben)<br>
  dieses Skript (GPL) setzt entsprechende SCSI Befehle ab<br>
- unter Linux: resize_reiserfs /dev/...    bzw. resize2fs /dev/...<br>
  geht beides.<br>
<br>
Meine Frage: Sind nach eurer Ansicht bei diesem Vorgehen Probleme zu erwarten ?<br>
<br>
Das Editieren der Partitionstabelle beim Vergrössern wäre eine Fehlerquelle, gleichzeitig braucht man keine Partitionstabelle mehr, für ein System am SAN oder ein virtuelles System. Dadurch dass ich &quot;by Label&quot; mounte, fällt es beim Handling nicht wirklich auf. Ich werde aber in die fstab einen dicken Hinweis schreiben.<br>

<br>
Im Moment habe ich als Last-Test einen bonnie++ in der Endlosschleife laufen, der so parametriert ist, dass er ueber die resizing-Schwellen auf der virtuellen Disk geht. Das will ich jetzt mal 2 Wochen beobachten.<br>
<br>
Storage Management auf Ebene SAN, auf Ebene Virtualisierung und dann noch LVM unter Linux , das ist meines Erachtens Overkill .<br>
<br>
Mich wundert dass so ein Vorgehen sonst nirgendwo beschrieben wird. Bin ich der einzige, der unglücklich ist, mit zusammengebackenen LVM-Devices und den zusätzlichen Physical Devices, die nur dazu da sind, eine andere Partition zu erweitern ?<br>

<br>
Winfried Büchert<br>
<font color="#888888"><br>
<br>
<br>
--<br>
NEU: FreePhone - kostenlos mobil telefonieren!<br>
Jetzt informieren: <a href="http://www.gmx.net/de/go/freephone" target="_blank">http://www.gmx.net/de/go/freephone</a><br>
<br>
_______________________________________________<br>
SAGE mailing list<br>
<a href="mailto:SAGE@guug.de">SAGE@guug.de</a><br>
<a href="http://lists.guug.de/mailman/listinfo/sage" target="_blank">http://lists.guug.de/mailman/listinfo/sage</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>= = =  <a href="http://michael-schuh.net/">http://michael-schuh.net/</a>  = = = <br>Projektmanagement - IT-Consulting - Professional Services IT<br>Michael Schuh<br>
Postfach 10 21 52<br>66021 Saarbrücken<br>phone: 0681/8319664<br>mobil:  0175/5616453<br>@: m i c h a e l . s c h u h @ g m a i l . c o m<br><br>= = =  Ust-ID:  DE251072318  = = =<br>
</div>