Festplattengröße bei Linux

[robotto7831a]

Hallo zusammen,

ich bekomme demnächst einen neuen Server in der Firma und der soll mit einer 80 oder 100 GB Festplatte ausgestattet sein (IDE).

Darauf soll Suse Linux 7.3 installiert werden mit ext2 Dateiformat.

Welche Partionsgrößen unterstützt Suse Linux?

Frank

[stormeater]

Servus,

hab was gefunden 4TB bei ext2

http://www.linuxfibel.de/limits.htm

[robotto7831a]

OK. Danke.

Frank

[janand2]

ext2 würde ich aber niemals verwenden... hast du kein neueres Suse??

[hart]

Was denn sonst?

[janand2]

na ext3 oder reiserfs... ist doch viel besser

brauchst halt ein neueres Suse.. oder Kernel updaten..

[hart]

Aber nicht für ein Produktiv-System! Da werd ich sowas bestimmt nicht einsetzen.

[janand2]

wieso nicht?? die Dateisysteme sind doch viel besser, oder etwa nicht??

[hart]

Original geschrieben von janand2

wieso nicht?? die Dateisysteme sind doch viel besser, oder etwa nicht??

Ließ dir mal diesen Artikel durch: http://www.dignatz.de/d/spotlight/artikel/russisches_roulette_linux-mag_20020605_001.html

[janand2]

uihh.. sorry das wusste ich nicht :confused: dachte immer das die besser seien, naja schon wieder was dazugelernt, danke

[FunkyBeat]

Was mir in dem Artikel fehlt, sind die Argumente. Ich höre nur, dass Reiserfs beim Check irgendwas an den Daten dreht, mich würde interessieren, was, wann, wo und wie es an den Daten dreht.

Auch würde mich interessieren, was genau die bemängelte Config-Einstellung abschaltet, den obligatorischen Log-Replay wohl eher nicht.

Außerdem hab ich das Gefühl, dass dieser tolle Berater nicht zwischen Data-Journaliing und Meta-Data Journalling unterscheidet (Reiser kann nur letzteres, Ext3 kann beides, büsst aber auch einen dicken Haufen Geschwindigkeit ein, wenn es denn so konfiguriert ist).

Inkonsistente Daten können bei Ext2 genauso gut vorkommen wie bei Reiser, der Unterschied liegt einzig und allein in den Meta-Daten, die bleiben (meistens) Konsistenz.

Somit ist (von evtl. Bugs abgesehen) ReiserFS genauso sicher wie Ext2, nur bei einem Neustart nach Absturz deutlich schneller wieder da. (und ext2 kann auf einer 80-100GB Platte sehr sehr sehr lange dauern...)

Ich mag ReiserFS gegenüber Ext2 vor allem wegen der Struktur beim Thema kleine Dateien (Tail-Packing, näheres auf der ReiserFS-Homepage, der erklärt das besser). Es gab allerdings Gerüchte, dass bis Kernel 2.4.16 ReiserFS gelegentlich Probleme gemacht hat, konkrete Einzelfälle hatte ich bis dahin aber nicht gefunden...

[hart]

Original geschrieben von FunkyBeat

Was mir in dem Artikel fehlt, sind die Argumente. Ich höre nur, dass Reiserfs beim Check irgendwas an den Daten dreht, mich würde interessieren, was, wann, wo und wie es an den Daten dreht.

Hatte grad den Link zu diesem Thema und wollte nicht extra wieder suchen.

Somit ist (von evtl. Bugs abgesehen) ReiserFS genauso sicher wie Ext2, nur bei einem Neustart nach Absturz deutlich schneller wieder da. (und ext2 kann auf einer 80-100GB Platte sehr sehr sehr lange dauern...)

Was heist von Bugs abgesehen, es wurden zwar viele behoben. Aber die Frage ist wie. Teilweise wurden nur dirty workarounds geschaffen die das Problem beheben, aber dadurch teilweise wieder gesamtfunktinalitäten aufgehoben wurden (unfsd). Auf einem Server hätte ich gern ein Dateisystem das sauber Programmiert ist, und auch in Ausnahme Situationen kontrolliert abläuft.

Ich mag ReiserFS gegenüber Ext2 vor allem wegen der Struktur beim Thema kleine Dateien (Tail-Packing, näheres auf der ReiserFS-Homepage, der erklärt das besser). Es gab allerdings Gerüchte, dass bis Kernel 2.4.16 ReiserFS gelegentlich Probleme gemacht hat, konkrete Einzelfälle hatte ich bis dahin aber nicht gefunden...

Sicher reiserfs hat viele Vorteile, nur deswegen werd ich es bestimmt nicht auf einem Produktivsystem einsetzten. Dann doch lieber xfs, da steckt einfach mehr Erfahrung drin.

[Irrlicht]

Hi Leute,

dazu kann ich aus leidvoller Erfahrung von heute auch eine kleine Story beitragen.

Ich kann jetzt nicht mit Sicherheit sagen, ob es wirklich an EXT3 liegt, oder ob ich mal

wieder irgend einen Sh** gemacht habe. Aber eigentlich glaube ich eher nicht an

einen Fehler meinerseits.

Na egal, hier also meine Erfahrungen.

Erstmal vorweg:

- System SuSE 8.0

- hda: Maxtor 60 GB

- hdb: Maxtor 40 GB

- FS: alles ext3 (bis auf /boot = hda1)

OK. Sollte eigentlich an Info langen.

Also ich habe bei meiner letzten Linux Installation verschiedene Partitionen auf hda

angelegt. hdb habe ich erstmal in Ruhe gelassen.

Hat danach dann ca. so ausgesehen:

hda1 auf /boot mit ext2 (32MB)

hda5 auf / mit ext3 (10GB)

hda6 auf /home mit ext3 (40 GB)

hda7 auf /var mit ext3 (Rest)

Dann habe ich ein paar Tage spaeter die 2. HD mit 2 Partitionen und ext3 formatiert.

War eigentlich auch ok. Bis auf folgendes:

Nachdem ich die Partitionen gemountet habe, ist mir beim 2. Zugriff darauf der

Rechner eingefroren.

Ich kanns mir irgendwie auch nicht erklaeren, dass der erste Zugriff keine

Probleme gemacht hat, der 2. aber immer den Rechner zum einfrieren gebracht hat.

Also es war immer reproduzierbar der 2. Zugriff.

Danach half dann nichts anderes mehr, als ein harter Reset. Das ging die ersten Male

auch gut, aber irgendwann hat er mir beim Booten den fsck nicht komplett auf der

Partition durchgefuehrt und ich sollte ihn manuell durchfuehren.

Habe ich mir gedacht, kein Problem, mach ich. Haha, denkste. Zuerst hat er mir das

Journal zerschossen und dann einfach ein ext2 draus gemacht.

Naja, waere auch alles kein Problem, wenn die Daten, die auf der Partition waren,

jetzt nicht total umbenannt und irgendwo in dem Verzeichnis lost&found irgendwie in

verschiedene Unterordner kopiert worden waeren.

Das Ergebnis ist jetzt, dass ich in diesem ominoesen Ordner ungefaehr 100

Unterordner habe, in denen meine Daten einfach irgendwo hingeschrieben sind.

Und wie gesagt, viele Daten sind umbenannt worden, sodass ich jetzt erstmal

suchen kann und den ganzen ******* wieder reparieren muss.

Soviel zu EXT3 und seinen journalling Faehigkeiten.

So long,

tkr

[hart]

Original geschrieben von Irrlicht

wieder irgend einen Sh** gemacht habe. Aber eigentlich glaube ich eher nicht an

einen Fehler meinerseits.

Sieht mir eher nach einem Fehler von Dir aus, als nach ext3.

[...]

Ich kanns mir irgendwie auch nicht erklaeren, dass der erste Zugriff keine

Probleme gemacht hat, der 2. aber immer den Rechner zum einfrieren gebracht hat.

Also es war immer reproduzierbar der 2. Zugriff.

Danach half dann nichts anderes mehr, als ein harter Reset. Das ging die ersten Male

auch gut,

Warum suchst Du nicht nach dem Fehler, sondern drückst immer den Reset Knopf?

Das hält das beste Dateisystem nicht auf dauer aus.

aber irgendwann hat er mir beim Booten den fsck nicht komplett auf der

Partition durchgefuehrt und ich sollte ihn manuell durchfuehren.

Welches Programm hast Du den genau gestartet?

[...]

Soviel zu EXT3 und seinen journalling Faehigkeiten.

Naja, hängt auch von Dir ab. Würd mich mal intereiesen welches Programm Du fürs checken gestartet hast und mit welchen Prarametern.

[Irrlicht]

Original geschrieben von hart

Sieht mir eher nach einem Fehler von Dir aus, als nach ext3.

Naja, wie gesagt, es koennte schon meine Schuld sein.

Aber kannst du mir mal sagen, was an den folgenden Schritten falsch ist?

1. Partitionieren

2. Mounten

3. Dateien kopieren

4. du -sh auf diese Partition

Ergebnis beim du -sh: Rechner friert ein.

Warum suchst Du nicht nach dem Fehler, sondern drückst immer den Reset Knopf?

Das hält das beste Dateisystem nicht auf dauer aus.

Du bist gut. Wie soll ich nach dem Fehler suchen, wenn das System so eingefroren

ist, dass gar nichts mehr geht? Nach meinem Verstaendnis geht dann nichts

anderes mehr, als den Reset Knopf zu druecken.

Ausserdem habe ich mich dumm und daemlich gesucht, konnte aber nichts

treffendes finden.

Welches Programm hast Du den genau gestartet?

Naja, hängt auch von Dir ab. Würd mich mal intereiesen welches Programm Du fürs checken gestartet hast und mit welchen Prarametern.

fsck -r

[Irrlicht]

Also, Mr. Hart,

was kannst du mir jetzt sagen, dass ich nicht wieder solche Probleme habe.

Eins vorweg:

Habe jetzt EXT2 im Einsatz und keine Probleme.

Ach ja, habe die gleichen Schritte unternommen, wie unter der

EXT3 Partitionierung. Scheint aber nicht die gleichen Schwierigkeiten hervorzurufen ...

So long,

tkr

PS: Nicht falsch verstehen, Mr. Hart ;-)

Will dir nicht ans Bein *****n. Geht nur um ein allgemeines Verstaendnis

[hart]

Original geschrieben von Irrlicht

Also, Mr. Hart,

was kannst du mir jetzt sagen, dass ich nicht wieder solche Probleme habe.

Was soll ich Dir sagen? Gut ist ja schon mal wenn Du das Problem Reproduzieren kannst. Wobei das mit dem du und Rechner einfrieren kenn ich nur von nfs und samba mounts.

Du könntest von der SuSE CD das Rettungssystem starten. Dann die Platte mit fdisk neu Partionieren und anschließend mit ext3 formatieren. Anschleßend normal mounten und eine 100MB Datei auf der neuen Platte erzeugen und beobachten was die messages sagt.

# (tail -f /var/log/messages &) && head -c 100m /dev/urandom > 100m

Eins vorweg:

Habe jetzt EXT2 im Einsatz und keine Probleme.

Ach ja, habe die gleichen Schritte unternommen, wie unter der

EXT3 Partitionierung. Scheint aber nicht die gleichen Schwierigkeiten hervorzurufen ...

Sicher keine Probleme? Du kannst also außschließend das die Platte, das Kabel, oder der Controller defekt sind?

[FunkyBeat]

Original geschrieben von hart

Hatte grad den Link zu diesem Thema und wollte nicht extra wieder suchen.

Hätte aber geholfen...

Was heist von Bugs abgesehen, es wurden zwar viele behoben. Aber die Frage ist wie. Teilweise wurden nur dirty workarounds geschaffen die das Problem beheben, aber dadurch teilweise wieder gesamtfunktinalitäten aufgehoben wurden (unfsd).

http://www.namesys.com/faq.html#nfs klingt weniger nach Schwächen im Code als designbedingte Inkompatibiltäten... Da würde ich mich über genauere Infos freuen

Auf einem Server hätte ich gern ein Dateisystem das sauber Programmiert ist, und auch in Ausnahme Situationen kontrolliert abläuft.

nicht beweisbar. Ich würde für einen Server eher sagen, dass ich kein so junges Filesystem nehmen würde, insbesondere weil es weniger Werkzeuge gibt als für Ext2, aber unsauber Programmiert, dafür gibt's keine Anhaltspunkte.

Sicher reiserfs hat viele Vorteile, nur deswegen werd ich es bestimmt nicht auf einem Produktivsystem einsetzten. Dann doch lieber xfs, da steckt einfach mehr Erfahrung drin.

Öchöt...

Da versteh ich dich überhaupt nicht, sorry. Der XFS-Patch Code für den Linux Kernel (ich meine nicht XFS selbst) ist um einiges grüner als ReiserFS (was sich wahrscheinlich im 2.6er Baum ändern wird:

http://www.geocrawler.com/lists/3/Suse-Linux/292/0/9429947/

) und die Tatsache, dass er sich mit so vielen anderen Sachen beisst (preempt und lowlat als Beispiel, aber die sind für Server nicht wichtig) zeigt auch, wie grün er noch ist...

[Irrlicht]

Original geschrieben von hart

Du könntest von der SuSE CD das Rettungssystem starten. Dann die Platte mit fdisk neu Partionieren und anschließend mit ext3 formatieren. Anschleßend normal mounten und eine 100MB Datei auf der neuen Platte erzeugen und beobachten was die messages sagt.

# (tail -f /var/log/messages &) && head -c 100m /dev/urandom > 100m

Werde ich bei Gelegenheit mal ausprobieren.

Aber momentan gibt es, wie schon gesagt, keine Probleme. Deswegen werde ich jetzt

nicht hingehen, und meine Platte neu formatieren. Aber ich warte mal ein

bisschen ab.

Sicher keine Probleme? Du kannst also außschließend das die Platte, das Kabel, oder der Controller defekt sind?

Kann ich natuerlich nicht direkt ausschliessen. Zumindest das der Controller

defekt ist. Das Kabel steckt aber fest in der Platte.

Ansonsten habe ich das eh erst seit gestern so im Einsatz (EXT2) und so viel

habe ich noch nicht auf die Platte geschrieben. Aber ein paar 100 MB sind

es dann doch schon und Probleme habe ich bisher noch nicht

entdecken koennen. Zumindest ist mir mein Rechner noch nicht wieder eingefroren.

Aber ich halte dich auf dem laufenden.

Ansonsten noch 'n schoenes Wochenende.

tkr

[hart]

Original geschrieben von FunkyBeat

http://www.namesys.com/faq.html#nfs klingt weniger nach Schwächen im Code als designbedingte Inkompatibiltäten... Da würde ich mich über genauere Infos freuen

Naja, mittlerweile sind die ja wieder weiter. Aber unfsd war auch nur als _ein_ Beispiel gedacht, wie vorgeganen wird.

nicht beweisbar.

Was ist nicht beweisbar? Wie sich ein Dateisystem in extrem Situationen verhält? Etwa wenn eine RAID5 Platte abraucht, die Hot-Disk einspringt und das LVM mit dem daraufbefindlichem Dateisystem verhält.

Ich würde für einen Server eher sagen, dass ich kein so junges Filesystem nehmen würde, insbesondere weil es weniger Werkzeuge gibt als für Ext2, aber unsauber Programmiert, dafür gibt's keine Anhaltspunkte.

Ganz Deiner Meinung!

Öchöt...

Da versteh ich dich überhaupt nicht, sorry.

Damit meinte ich natürlich nicht das ich wenn ich die Wahl hätte zwischen Reiserfs, xfs, ext3 und ext2, sofort xfs einsetzen werden. Aber wenn es xfs Stable auch auf Linux geben würde, würde ich das den anderen vorziehen. Weil xfs von anderen unixen genung Praxis hat.

Stell grad fest, warum das hier das einzigste Forum ist, wo ich schreibe. Das quoting bei mailinglisten geht einfach besser und man hat vi.