Hallo Liste, mal eine Frage zu Suse 7.1, Reiserfs und LVM: Einleitung: Im Moment verwende ich Suse 7.0 und LVM mit 2x 30 GB Festplatte (ext2). Nun möchte ich im Zuge der Umstellung auf den 2.4 Kernel mit Suse 7.1 auf Reiserfs umstellen und zusätzlich noch eine 1x 60 GB Platte dazunehmen. Zusätzlich existiert noch eine "normale" 40 gig platte im System, auf der die üblichen Verzeichnisse sind. Von Reiserfs muß also nicht gebootet werden. Fragen: a) Nach Studium der Homepage komme ich zu dem Schluss, daß reiserfs keine Platten zusammenfassen kann. Daher benötige ich auch bei reiserfs den LVM. Richtig ? b) Gibt es für Reiserfs ein Tool wo ich die Partionsgrößen im laufenden Betrieb ändern kann ? (z.B. ext2: resize2fs) c) ich wollte wie folgt vorgehen: neue 60gig platte als neues LVM konfigurieren, als reiserfs partionieren, die alte LVM Partition (2x 30 Gig) drauf kopieren, die alte LVM Partition löschen und zu der neuen hinzufügen und als reiserfs definieren. Klappt das so ? d) gibt es ein deutsches Howto/FAQ zu reiserfs `` cu Stonki
Stefan Onken schrieb:
Hallo Liste,
[...]
Fragen:
a) Nach Studium der Homepage komme ich zu dem Schluss, daß reiserfs keine Platten zusammenfassen kann. Daher benötige ich auch bei reiserfs den LVM. Richtig ?
Ja.
b) Gibt es für Reiserfs ein Tool wo ich die Partionsgrößen im laufenden Betrieb ändern kann ? (z.B. ext2: resize2fs)
Ja. Ich mache das immer im Yast. Man kann aber nicht verkleinern, also sollte man etwas Platz lassen.
c) ich wollte wie folgt vorgehen: neue 60gig platte als neues LVM konfigurieren, als reiserfs partionieren, die alte LVM Partition
Nö, man "partitioniert kein Reiserfs" das ist eine Volume, Partitionieren tut man die Festplatte.
(2x 30 Gig) drauf kopieren, die alte LVM Partition löschen und zu der neuen hinzufügen und als reiserfs definieren. Klappt das so ?
Das sollte man können.
d) gibt es ein deutsches Howto/FAQ zu reiserfs `` Ich habe keins gefunden, also nicht unter /usr/share/doc, Vieleicht auf dem LDP Server.
-- Helmut Mail komplett ohne M$ Programme erstellt! Adressen und Öffentliche Schlüssel: Firma : hefa@bitctrl.de ID: ED047376 Privat: hefa@gmx.net ID: 12622C98 Server: wwwkeys.de.pgp.net Linux - Waehrend man in Redmond noch bootet, wird in Villa Pinguin schon gearbeitet...
Stefan Onken wrote:
Hallo Liste,
mal eine Frage zu Suse 7.1, Reiserfs und LVM:
Einleitung: Im Moment verwende ich Suse 7.0 und LVM mit 2x 30 GB Festplatte (ext2). Nun möchte ich im Zuge der Umstellung auf den 2.4 Kernel mit Suse 7.1 auf Reiserfs umstellen und zusätzlich noch eine 1x 60 GB Platte dazunehmen. Zusätzlich existiert noch eine "normale" 40 gig platte im System, auf der die üblichen Verzeichnisse sind. Von Reiserfs muß also nicht gebootet werden.
Fragen:
a) Nach Studium der Homepage komme ich zu dem Schluss, daß reiserfs keine Platten zusammenfassen kann. Daher benötige ich auch bei reiserfs den LVM. Richtig ?
Zusammenfassen können weder reiserfs noch ext2.
b) Gibt es für Reiserfs ein Tool wo ich die Partionsgrößen im laufenden Betrieb ändern kann ? (z.B. ext2: resize2fs) Nein, gibt es nicht. Desweiteren gibt es bislang auch kein dump (o.ä) und auch kein vernünfiges fsck.
c) ich wollte wie folgt vorgehen: neue 60gig platte als neues LVM konfigurieren, als reiserfs partionieren, die alte LVM Partition (2x 30 Gig) drauf kopieren, die alte LVM Partition löschen und zu der neuen hinzufügen und als reiserfs definieren. Klappt das so ? Sollte gehen.
Doch Du gestattest doch die Frage: Ca. 100 GB auf einem Desktop? Dann spricht eigentlich nichts gegen reiserfs/lvm. Falls es sich jedoch um einen Server handelt, würde ich ext2 einsetzen, auch bei 100GB, da auf einem Server selbst die ca. 1Std. Filecheck im Absturzfall tolerierbar sind, ein einzelner Datenverlust hingegen nicht. Ob das merkwürdige Zeitverhalten von Reiserfs bei 100GB noch erträglich ist kann ich nicht beurteilen (Gelegentliche, u.U. mehrere Sek. lange Hänger beim Zugriff auf's Filesystem - Hat schon gestern jemand anderes in einem anderen Thread erwähnt. Kann ich aus eigener Erfahrung bestätigen :).
d) gibt es ein deutsches Howto/FAQ zu reiserfs `` Keine Ahnung. Ich bevorzuge Original-Howtos (Auch wenn sie im Fall von Reiserfs in Germinglish bzw. Russinglish geschrieben sind. :)
Ralf
Hi Liste nach ner Neuinstallation und anpassen der httpd.conf spinnt der Apache die Virtualhosts laufen, nur nicht ständig, mehrmaliges aktualisieren erst 404 dann springt er auf die Haupdomäne, dann wieder 404 u.s.w. die virtual : <VirtualHost IP> Serveradmin root@hauptdomäne.com ServerName www.hauptdomäne.com DocumentRoot /usr/local/httpd/htdocs/ RewriteEngine On RewriteRule ^(/usr/local/httpd/htdocs/.*) /usr/local/httpd/htdocs$1 DocumentRoot /usr/local/httpd/htdocs HostNameLookups on </VirtualHost> <VirtualHost selbe IP> ServerAdmin root@hauptdomäne.com ServerName subdomäne.hauptdomäne.com DocumentRoot /usr/local/httpd/htdocs/subdomäne/ RewriteEngine On RewriteRule ^(/usr/local/httpd/htdocs/subdomäne.*) /usr/local/httpd/htdocs/subdomäne$1 ErrorLog /var/log/virtual/subdomäne/error_log CustomLog /var/log/virtual/subdomäne/access_log common HostNameLookups on </VirtualHost> die Einträge RewriteEngine On RewriteRule ^(/usr/local/httpd/htdocs/.*) /usr/local/httpd/htdocs$1 hab ich von apache org, haben nix gebracht, ebenso das HostLokup :( DNS löst korreckt auf ist der Indianer überfordert ? er startet mit backhand php4 ssl... weis jemand die Lösung ? Thx Günther
Am Freitag, 16. Februar 2001 17:36 schrieb Günther Höpfner:
nach ner Neuinstallation und anpassen der httpd.conf spinnt der Apache
Besorg dir den 1.3.17er vom SuSE-FTP-Server. Dass der da liegt hat seinen guten Grund, der 1.3.14er hat hier auch mit VirtualHosts seine Probleme. PS: Bitte häng Deine Anfragen nicht in bestehende Threads, das hat mit ReiserFS nicht das geringste zu tun. -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de
Hi Manfred, hi Liste
Besorg dir den 1.3.17er vom SuSE-FTP-Server. Dass der da liegt hat seinen guten Grund, der 1.3.14er hat hier auch mit VirtualHosts seine Probleme. danke hab schon von indianer.org und gleich selber gebaut
PS: Bitte häng Deine Anfragen nicht in bestehende Threads, das hat mit ReiserFS nicht das geringste zu tun. sorry, war so wütend hab total getrieft
mfg Günther
Hi, * On Friday, February 16, 2001 at 17:13, Ralf Corsepius wrote:
Stefan Onken wrote: [...]
b) Gibt es für Reiserfs ein Tool wo ich die Partionsgrößen im laufenden Betrieb ändern kann ? (z.B. ext2: resize2fs) Nein, gibt es nicht. Desweiteren gibt es bislang auch kein dump (o.ä) und auch kein vernünfiges fsck.
Doch. mount -o remount,resize=xxxxx /dev/vg00/usr Wobei xxxxx die Anzahl der Blöcke ist, d.h. die Größe der Partition dividiert durch die Blockgröße. Die ist bei meinen FS'en 4k. Ich weiß allerdings nicht, wie Du die rausfindest; Du kannst Dich allerdings nach Lust und Laune mit mount herumspielen, weil das FS nur größer werden kann, aber nicht übers Ziel rausschießt, weil beim resizen geprüft wird, ob der letzte Block auch fehlerfrei lesbar ist. Und offline kannst du resize_reiserfs verwenden. Mit Backup und ein wenig Nervekitzel kannst Du da auch verkleinern - ist noch alpha und absolut unempfohlen, hat bis dato aber immer funktioniert. Allerdings hatte ich immer ein Backup rumliegen ...
c) ich wollte wie folgt vorgehen: neue 60gig platte als neues LVM konfigurieren, als reiserfs partionieren, die alte LVM Partition (2x 30 Gig) drauf kopieren, die alte LVM Partition löschen und zu der neuen hinzufügen und als reiserfs definieren. Klappt das so ? Sollte gehen.
Blöde Frage: warum fügst Du das neue PV nicht einfach zu der alten VG hinzu? Wenn Du die Daten unbedingt auf der neuen Platte liegen haben willst, dann kannst Du die alten 2 auch mit pvmove freischaufeln, scheint mir zuverlässiger.
Doch Du gestattest doch die Frage: Ca. 100 GB auf einem Desktop? Dann spricht eigentlich nichts gegen reiserfs/lvm.
Falls es sich jedoch um einen Server handelt, würde ich ext2 einsetzen, auch bei 100GB, da auf einem Server selbst die ca. 1Std. Filecheck im Absturzfall tolerierbar sind,
1 Std bei 100GB? Klingt nach einem schnellen RAID-Array ...
ein einzelner Datenverlust hingegen nicht.
... ich kenne keinen Fall, wo reiserfs Datenverlust verursachte - und ansonsten, sollte für diesen Fall sowieso ein Backup rumliegen.
Ob das merkwürdige Zeitverhalten von Reiserfs bei 100GB noch erträglich ist kann ich nicht beurteilen (Gelegentliche, u.U. mehrere Sek. lange Hänger beim Zugriff auf's Filesystem - Hat schon gestern jemand anderes in einem anderen Thread erwähnt. Kann ich aus eigener Erfahrung bestätigen :).
Das scheint auch nur bei bestimmten Personen aufzutreten - ich konnte das noch nie nachvollziehen. Adalbert
Today, Adalbert Michelic sleept on the keyboard and thought about Re:...
... ich kenne keinen Fall, wo reiserfs Datenverlust verursachte - und ansonsten, sollte für diesen Fall sowieso ein Backup rumliegen.
dito bis jetzt auf 70GB Fileserver mit 50 Clients keine Probs
Ob das merkwürdige Zeitverhalten von Reiserfs bei 100GB noch erträglich ist kann ich nicht beurteilen (Gelegentliche, u.U. mehrere Sek. lange Hänger beim Zugriff auf's Filesystem - Hat schon gestern jemand anderes in einem anderen Thread erwähnt. Kann ich aus eigener Erfahrung bestätigen :).
Das scheint auch nur bei bestimmten Personen aufzutreten - ich konnte das noch nie nachvollziehen.
dito kein Probs oder auffälligkeiten dahingehend gregor -- Gregor Hlawacek Austria http://www.unileoben.ac.at/~m9327555/ May the source be with you! This posting is 100% M$ free. Guaranteed by Tux, the friendly penguin.
Adalbert Michelic wrote:
Hi,
* On Friday, February 16, 2001 at 17:13, Ralf Corsepius wrote:
Stefan Onken wrote: [...]
b) Gibt es für Reiserfs ein Tool wo ich die Partionsgrößen im laufenden Betrieb ändern kann ? (z.B. ext2: resize2fs) Nein, gibt es nicht. Desweiteren gibt es bislang auch kein dump (o.ä) und auch kein vernünfiges fsck.
Doch. mount -o remount,resize=xxxxx /dev/vg00/usr
Wobei xxxxx die Anzahl der Blöcke ist, d.h. die Größe der Partition dividiert durch die Blockgröße. Die ist bei meinen FS'en 4k. Ich weiß allerdings nicht, wie Du die rausfindest; Du kannst Dich allerdings nach Lust und Laune mit mount herumspielen, weil das FS nur größer werden kann, aber nicht übers Ziel rausschießt, weil beim resizen geprüft wird, ob der letzte Block auch fehlerfrei lesbar ist.
Aha, immer mal wieder was neues. :)
Doch Du gestattest doch die Frage: Ca. 100 GB auf einem Desktop? Dann spricht eigentlich nichts gegen reiserfs/lvm.
Falls es sich jedoch um einen Server handelt, würde ich ext2 einsetzen, auch bei 100GB, da auf einem Server selbst die ca. 1Std. Filecheck im Absturzfall tolerierbar sind,
1 Std bei 100GB? Klingt nach einem schnellen RAID-Array ...
War eine Hochrechnung aus meinen ca 30GB auf U2W SCSI Platten. Ein Ext2-fsck über alles dauert ca. 15-20 Minuten.
ein einzelner Datenverlust hingegen nicht.
... ich kenne keinen Fall, wo reiserfs Datenverlust verursachte - und ansonsten, sollte für diesen Fall sowieso ein Backup rumliegen. Dann stöber mal im Listenarchiv. Es hatten schon einige Leute über derartige Verluste berichtet. Ich hatte zu SuSE 6.4-Zeiten mal eine kleine reiserfs-Partition bei Experimenten auf mit meinen SMP-Rechner verloren.
Ob das merkwürdige Zeitverhalten von Reiserfs bei 100GB noch erträglich ist kann ich nicht beurteilen (Gelegentliche, u.U. mehrere Sek. lange Hänger beim Zugriff auf's Filesystem - Hat schon gestern jemand anderes in einem anderen Thread erwähnt. Kann ich aus eigener Erfahrung bestätigen :).
Das scheint auch nur bei bestimmten Personen aufzutreten :) Könnte auch von der Art der Nutzung abhängen. Bei mir in erster Linie heftige Kompilerläufe und rechenintensive Simulationen.
- ich konnte das noch nie nachvollziehen. Könnte in meinem Fall auch an mangelnder SMP-Integration eines Treibers oder von reiserfs liegen.
Ralf
Hi, * On Friday, February 16, 2001 at 19:10, Ralf Corsepius wrote:
Adalbert Michelic wrote:
1 Std bei 100GB? Klingt nach einem schnellen RAID-Array ...
War eine Hochrechnung aus meinen ca 30GB auf U2W SCSI Platten. Ein Ext2-fsck über alles dauert ca. 15-20 Minuten.
Falls ich nicht daneben liege, steigt der Zeitverbrauch von e2fsck nicht linear sondern ca. quadratisch ....
... ich kenne keinen Fall, wo reiserfs Datenverlust verursachte - und ansonsten, sollte für diesen Fall sowieso ein Backup rumliegen.
Dann stöber mal im Listenarchiv. Es hatten schon einige Leute über derartige Verluste berichtet.
Ich weiß, daß schon manche über Datenverluste klagten - aber da waren immer Sachen dabei, wo ich mir dachte, da darf man sich einfach nicht wundern, daß einem der Benzinkanister um die Ohren fliegt, wenn man mit einem Feuerzeug nachsieht, ob noch was drinn ist :-)
Ich hatte zu SuSE 6.4-Zeiten mal eine kleine reiserfs-Partition bei Experimenten auf mit meinen SMP-Rechner verloren.
Ob das merkwürdige Zeitverhalten von Reiserfs bei 100GB noch erträglich ist kann ich nicht beurteilen (Gelegentliche, u.U. mehrere Sek. lange Hänger beim Zugriff auf's Filesystem - Hat schon gestern jemand anderes in einem anderen Thread erwähnt. Kann ich aus eigener Erfahrung bestätigen :).
Das scheint auch nur bei bestimmten Personen aufzutreten :) Könnte auch von der Art der Nutzung abhängen. Bei mir in erster Linie heftige Kompilerläufe und rechenintensive Simulationen.
- ich konnte das noch nie nachvollziehen. Könnte in meinem Fall auch an mangelnder SMP-Integration eines Treibers oder von reiserfs liegen.
Beim Kompilieren hatte ich bis dato auch nix bemerkt, aber möglicherweise gibt's mit SMP Probleme, da habe ich erstens keine Erfahrung, zweitens erscheit es mir sehr leicht möglich, daß da hinterhältige Probleme auftauchen, wenn mehrere Prozessoren im Spiel sind. Adalbert
On Fri, Feb 16, 2001, Ralf Corsepius wrote: Hallo,
Adalbert Michelic wrote:
Doch Du gestattest doch die Frage: Ca. 100 GB auf einem Desktop? Dann spricht eigentlich nichts gegen reiserfs/lvm.
Falls es sich jedoch um einen Server handelt, würde ich ext2 einsetzen, auch bei 100GB, da auf einem Server selbst die ca. 1Std. Filecheck im Absturzfall tolerierbar sind,
1 Std bei 100GB? Klingt nach einem schnellen RAID-Array ...
War eine Hochrechnung aus meinen ca 30GB auf U2W SCSI Platten. Ein Ext2-fsck über alles dauert ca. 15-20 Minuten.
Ich habe es mal auf ca. 25 GB Daten laufen lassen müssen, kann mich aber leider nicht mehr dran erinnern, wie lange das lief. Aber grob geschätzt wirst Du für die 100 GB 1 bis 2 Stunden brauchen. Es gibt natürlich auch uninterruptable powersupplies.
Ob das merkwürdige Zeitverhalten von Reiserfs bei 100GB noch erträglich ist kann ich nicht beurteilen (Gelegentliche, u.U. mehrere Sek. lange Hänger beim Zugriff auf's Filesystem - Hat schon gestern jemand anderes in einem anderen Thread erwähnt. Kann
Könnte ich gewesen sein. ;-)
ich aus eigener Erfahrung bestätigen :).
Das scheint auch nur bei bestimmten Personen aufzutreten :) Könnte auch von der Art der Nutzung abhängen. Bei mir in erster Linie heftige Kompilerläufe und rechenintensive Simulationen.
- ich konnte das noch nie nachvollziehen. Könnte in meinem Fall auch an mangelnder SMP-Integration eines Treibers oder von reiserfs liegen.
Hier ging es auch erst gut. (Volume mit ca. 25 GB Daten und etwa einem Dutzend Benutzern gleichzeitig.) Und dann habe ich von user- nfs nach knfs gewechselt, und alles ging den Bach runter... Datenverlust hatte ich keinen bemerkt, nur das Zeitverhalten war unerträglich. Und zurück nach ext2. Ich werde wohl damit auf 7.2 warten, dann dürfte es funzen. MfG Gunther -- Dipl.-Ing. Gunther Kuhlmann Gunther_Kuhlmann@mentorg.com Tel.: +44 (0)12 52 / 74 83 25 PGP: E6 BC 78 6B E6 09 C7 16 AB 5D 9A 9A D7 1C 01 FB --
Hi, * On Friday, February 16, 2001 at 21:11, Gunther Kuhlmann wrote: [Aussetzer und Datenverlust bei ReiserFS]
Hier ging es auch erst gut. (Volume mit ca. 25 GB Daten und etwa einem Dutzend Benutzern gleichzeitig.) Und dann habe ich von user- nfs nach knfs gewechselt, und alles ging den Bach runter...
Datenverlust hatte ich keinen bemerkt, nur das Zeitverhalten war unerträglich. Und zurück nach ext2. Ich werde wohl damit auf 7.2 warten, dann dürfte es funzen.
Zu nfs kann ich nichts sagen, da habe ich den Vorteil, daß ich es nicht brauche, deswegen machen mir die Probleme im Zusammenhang mit nfs nix aus :-) Adalbert
Gunther Kuhlmann wrote:
On Fri, Feb 16, 2001, Ralf Corsepius wrote:
Hallo,
Adalbert Michelic wrote:
Doch Du gestattest doch die Frage: Ca. 100 GB auf einem Desktop? Dann spricht eigentlich nichts gegen reiserfs/lvm.
Falls es sich jedoch um einen Server handelt, würde ich ext2 einsetzen, auch bei 100GB, da auf einem Server selbst die ca. 1Std. Filecheck im Absturzfall tolerierbar sind,
1 Std bei 100GB? Klingt nach einem schnellen RAID-Array ...
War eine Hochrechnung aus meinen ca 30GB auf U2W SCSI Platten. Ein Ext2-fsck über alles dauert ca. 15-20 Minuten.
Ich habe es mal auf ca. 25 GB Daten laufen lassen müssen, kann mich aber leider nicht mehr dran erinnern, wie lange das lief. Aber grob geschätzt wirst Du für die 100 GB 1 bis 2 Stunden brauchen.
Dürfte m.M. nach hinkommen.
Es gibt natürlich auch uninterruptable powersupplies. Auf der anderen Seite: NVidia-Treiber.
Täglich 2-4 mal Rebooten zu müssen (0.9-4 und 0.9-5 Treiberversionen) war für mich ausreichend Grund einige weniger wichtige Partitionen auf ReiserFS zu konvertieren und ReiserFS eine Chance zu geben :)
Ob das merkwürdige Zeitverhalten von Reiserfs bei 100GB noch erträglich ist kann ich nicht beurteilen (Gelegentliche, u.U. mehrere Sek. lange Hänger beim Zugriff auf's Filesystem - Hat schon gestern jemand anderes in einem anderen Thread erwähnt. Kann
Könnte ich gewesen sein. ;-) Ja, ich habe gerade noch mal nachgesehen, meine Bemerkung hatte sich auf dich bezogen :).
Könnte in meinem Fall auch an mangelnder SMP-Integration eines Treibers oder von reiserfs liegen.
Hier ging es auch erst gut. (Volume mit ca. 25 GB Daten und etwa einem Dutzend Benutzern gleichzeitig.) Und dann habe ich von user- nfs nach knfs gewechselt, und alles ging den Bach runter... Ich verwende u.a. aufgrund der gleichen Erfahrung noch user-space nfs. [Vielleicht wäre es auch dort an der Zeit mal wieder einen Versuch mit knfs zu starten.]
Ralf
Today, Ralf Corsepius sleept on the keyboard and thought about Re: Reiserfs...
b) Gibt es für Reiserfs ein Tool wo ich die Partionsgrößen im laufenden Betrieb ändern kann ? (z.B. ext2: resize2fs) Nein, gibt es nicht. Desweiteren gibt es bislang auch kein dump (o.ä) und auch kein vernünfiges fsck.
Gibts doch resize_reiserfs!!!! funkt auch habs schon ein zweimal versucht theoretisch in beide richtungen aber beim verkleiner killt er halt daten aber das volum läßt sich verkleinern und wenn du glück hast (mehr is es wirklich nicht) geht nix verloren. vergrößern ging aufjedenfall ohne probs gregor -- Gregor Hlawacek Austria http://www.unileoben.ac.at/~m9327555/ May the source be with you! This posting is 100% M$ free. Guaranteed by Tux, the friendly penguin.
Hallo Ralf Corsepius, Am Freitag, 16. Februar 2001 um 17:15 schriebst Du:
b) Gibt es für Reiserfs ein Tool wo ich die Partionsgrößen im laufenden Betrieb ändern kann ? (z.B. ext2: resize2fs) RC> Nein, gibt es nicht. Desweiteren gibt es bislang auch kein dump RC> (o.ä) und auch kein vernünfiges fsck.
dann macht doch die Verwendung mit LVM für mich überhaupt keinen Sinn. Da meine langfristige Überlegung doch dahin ging, im Laufe der Zeit noch paar Platten dazu zu nehmen. Wenn das aber nicht möglich ist (da man die Partition nicht erweitern kann), macht das doch keinen Sinn. RC> Doch Du gestattest doch die Frage: Ca. 100 GB auf einem Desktop? RC> Dann spricht eigentlich nichts gegen reiserfs/lvm. Ca. 100 GB auf einem Desktop. Das sind die gesammelten MP3 Werke von meinen ganzen CD's. Und nun fange ich noch an, meine alten Platten (soweit sinnvoll) umzuwandeln. RC> Falls es sich jedoch um einen Server handelt, würde ich ext2 RC> einsetzen, auch bei 100GB, da auf einem Server selbst die ca. 1Std. hmm. Diese Aussage überrascht mich ein wenig. Ich hätte mir die Antwort umgedreht vorgestellt *g*. Ich muss ja nicht Reiserfs benutzen um meinen Spieltrieb zu befriedigen, sondern dachte eigentlich, es wäre die professionellere Variante, die Weiterverwendung von ext2 hätte immerhin den vorteil, daß ich die bestehende Partition einfach nur erweitern muss. Ich dachte nur, ext2 ist für > 100GB nicht geeignet. -- Mit freundlichen Grüssen Stefan Onken
Stefan Onken wrote:
Hallo Ralf Corsepius,
Auch Hallo,
Am Freitag, 16. Februar 2001 um 17:15 schriebst Du:
RC> Doch Du gestattest doch die Frage: Ca. 100 GB auf einem Desktop? RC> Dann spricht eigentlich nichts gegen reiserfs/lvm.
Ca. 100 GB auf einem Desktop. Das sind die gesammelten MP3 Werke von meinen ganzen CD's. Und nun fange ich noch an, meine alten Platten (soweit sinnvoll) umzuwandeln. Platten == Schallplatten? Interessant :)
RC> Falls es sich jedoch um einen Server handelt, würde ich ext2 RC> einsetzen, auch bei 100GB, da auf einem Server selbst die ca. 1Std.
hmm. Diese Aussage überrascht mich ein wenig. Ich hätte mir die Antwort umgedreht vorgestellt *g*. Ich muss ja nicht Reiserfs benutzen um meinen Spieltrieb zu befriedigen, sondern dachte eigentlich, es wäre die professionellere Variante, Kurze Anwort: Mir ist ReiserFS noch nicht ausgereift genug.
die Weiterverwendung von ext2 hätte immerhin den vorteil, daß ich die bestehende Partition einfach nur erweitern muss. Ich dachte nur, ext2 ist für > 100GB nicht geeignet. Lange Antwort:
Ausser den, bei diesen Plattengrössen grossen fsck-Zeiten, wüsste ich nicht warum das nicht gehen sollte. ReiserFS hat den Vorteil, im Falle eines Systemabsturzes in sehr vielen Fällen _schnell_ booten und die Daten wiederherstellen zu können. Auch wenn jetzt die ReiserFS-Fans widersprechen werden ;), ist meiner Erfahrung nach die Wahrscheinlichkeit, dass ein derartiger Fall bei ReiserFS auftritt höher wie bei ext2 (Siehe auch die recht eindeutigen ReiserFS-bezogenen Einträge in ftp://ftp.suse.com/pub/people/mantel/next/lx_sus22.changes). Wird es nach einem Absturz wirklich dann ernst, bietet ext2 die besseren Mittel sein FS wieder restaurieren zu können (fsck, dump). Man sollte auch nicht vergessen, was 100GB eigentlich sind: Da werden auch Backups zum ernsten Problem. Etwas überspitzt formuliert: Lieber 10x mehrere Stunden auf fsck warten, als 100x schnell und fehlerfrei zu rebooten und 1x die Daten in mehrtägiger Arbeit restaurieren zu müssen (100GB => ca.150CDs oder mehrere Dutzend Backup-Tapes). Deshalb zählt m.M. nach bei dieser Plattengrössenordnung eigentlich nur noch Ausfallsicherheit, da einziger Fall die Daten restaurieren zu müssen kaum noch hinzunehmen wäre. Aus diesem Grund würde ich für einen Server ext2 einsetzen, begleitet von weiteren Massnahmen, wie einem Backupkonzept, UPS, Raid, redundante Standby-Mirror usw. und dann darauf setzen, dass kein Ausfall auftritt. Für "Home-Desktopsysteme" wären diese Massnahmen wohl meist übertrieben. Gruss, Ralf
Hallo Ralf Corsepius, Am Montag, 19. Februar 2001 um 18:42 schriebst Du: RC> Platten == Schallplatten? Interessant :) ja, gute alte Ska, Reggae, Oi, Nothern Soul, Punk :-)Wem Billy Bragg und Redskins noch was sagen.... RC> Wird es nach einem Absturz wirklich dann ernst, bietet ext2 die RC> besseren Mittel sein FS wieder restaurieren zu können (fsck, dump). RC> Man sollte auch nicht vergessen, was 100GB eigentlich sind: Da RC> werden auch Backups zum ernsten Problem. naja, dann bleib ich doch lieber bei ext2. Spart mir auch die ganze hin- und her kopieren. RC> Für "Home-Desktopsysteme" wären diese Massnahmen wohl meist RC> übertrieben. auch wenn nun wahrscheinlich alle die Hände über den Kopf zusammenschlagen werden: ich spiegele die Daten mittels ASDL Anschluss mit einem Freund. Der Hauptabgleich natürlich einmal im Lan, der Rest dann so.... Wenn nun mal die Kiste abraucht (ganz am Anfang ist mir ne 10 gig platte mal zu heiss geworden, daher nun ein "richtiges" Gehäuse), hab ich zwar nie den aktuellen Stand, aber mal ganz ehrlich: mp3 ist auch nicht soooo wichtig. cu stonki
participants (8)
-
Adalbert Michelic -
Gregor Hlawacek -
Gunther Kuhlmann -
Günther Höpfner -
Helmut Fahrion -
Manfred Tremmel -
Ralf Corsepius -
Stefan Onken