Wer hat denn einen möglichen neuen Patch im Dauertest auf möglichst vielen Umgebungen getestet??? Niemand. Nein Danke, meine Daten sind mir wichtiger. Punkt.
sorry aber gerade in ext3 ist das mal wieder unverzeihbar, weil man dort ja am ehesten Stabilität erwartet. Ich kann mich noch sehr gut an FC3 erinnern dort hat die grub-installation auf einigen System zum kompletten Datenverlust geführt. Es gab nicht mal eine Bugfix-CD ;-( Es war auch nie klar warum Fedora ausgerechnet eine alte und völlig fehlerhafte grub-version auf die CD packen musste. Das mit dem Enterprise kann ich daher nur unterstreichen. Mein Rat: Niemals Produktivsysteme auf FC installieren, selbst nach monatelangen Patchorgien kann da niemand für Stabilität garantieren. Ich frage mich überhaupt allen ernstes ob es nicht besser wäre OpenSuse und FC von Community sites zu verbannen, im besten Fall ist das eine schlechte Werbung für deren Enterprise-Produkte.
Nein tut er nicht, zumindest steht er nicht im Kernel-Bugzilla. Also ist Fedora schuld und er tritt nur im Fedora-Kernel auf. Vermutlich hängt es das mit der fehlerhaften Compilerversion zusammen die Fedora alle Jahre wieder verwendet um ihre Distro so inkompatibel wie möglich zu halten.
Soweit ich das sehe, ist der im Kernel-Bugzilla noch garnicht enthalten.
http://kernelslacker.livejournal.com/tag/ext3 belegt aber, dass es den vanilla-kernel betrifft. Dave Jones ist zwar RedHat-Entwickler, allerdings vertaue ich ihm schon so weit, dass er auch wirklich mit einem vanilla-2.6.18 getestet hat, wenn er das schreibt.
Nur weil der Bug unter Fedora im Vanilla Kernel auftritt muss er deshalb noch nicht im Kernel selber sein. Fedora rühmt sich ja auch dieses mal wieder damit extra tolle patches eingepflegt zu haben. Da steht ja gross: "It isn't helping that it can only be reproduced on my box" vielleicht sollte man Linx auch mal lesen nicht nur posten
> Nur weil der Bug unter Fedora im Vanilla Kernel auftritt muss er deshalb > noch nicht im Kernel selber sein.
*lol* Wenn ein Vanilla-Kernel OOPS't dann ist es IMMER ein Problem des Kernels !
Und: Hör mal mit diesem "extra dolle patches märchen auf". Jede und ich meine JEDE Distri muss Vanilla Kernels patchen (wurde aber in diesem Topic auch schon angesprochen).
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0077 Thanks to Paul Starzetz for finding and researching this issue. (* Security fix *) patches/packages/kernel-ide-2.4.24-i486-2.tgz: Patched, recompiled. (* Security fix *) patches/packages/kernel-source-2.4.24-noarch-2.tgz: Patched the kernel source with a fix for the mremap() problem from Solar Designer, and updated the Speakup driver (not pre-applied). (* Security fix *)
So, wenn ich jetzt nicht völlig falsch liege, handelt es sich um folgenden Bug (+Fix):
[PATCH] jbd: fix commit of ordered data buffers
Original commit code assumes, that when a buffer on BJ_SyncData list is locked, it is being written to disk. But this is not true and hence it can lead to a potential data loss on crash. Also the code didn't count with the fact that journal_dirty_data() can steal buffers from committing transaction and hence could write buffers that no longer belong to the committing transaction. Finally it could possibly happen that we tried writing out one buffer several times.
The patch below tries to solve these problems by a complete rewrite of the data commit code. We go through buffers on t_sync_datalist, lock buffers needing write out and store them in an array. Buffers are also immediately refiled to BJ_Locked list or unfiled (if the write out is completed). When the array is full or we have to block on buffer lock, we submit all accumulated buffers for IO.
[suitable for 2.6.18.x around the 2.6.19-rc2 timeframe]
> Der Bug tritt bei einem Vanilla (Orginal Ungepatchtem !!) Linux Kernel auf.
Und jetzt überlegt mal jeder, warum es vielleicht doch nicht so toll ist, ext3 kontinuierlich zu erweitern und zu optimieren und warum das Reiser-Team will, dass an ReiserFS 3 *nur* Bugfixe vorgenommen werden sollen, während Erweiterungen, neue Features und Optimierungen in einem neuen Dateisystem stattfinden sollen.
Von ext3 gibt es mind. ein Dutzend verschiedene Hauptversionen, die nur abwärts (nicht aufwärts) zueinander kompatibel sind, aber alle den gleichen Namen, aber dafür unterschiedliche Bugs haben. Der immer identisch gehaltene Name suggeriert Stabilität, das ist marketingtechnisch für Red-Hat sehr vorteilhaft.
Zum Glück konnten sich die übrigen Kernelhacker zuletzt durchsetzen und haben verhindert, dass die neuesten, noch tiefer gehenden Änderungen ebenfalls im "stabilen" ext3 getestet werden. Nun gibt's ext4, aber allein schon der Versuch, ein neues Dateisystem unter dem alten Namen entwickeln zu wollen, sollte jedem, dem seine Daten lieb sind, zu Denken geben. Aber mit ReiserFs und Xfs gibt es ja leistungsfähige(re) und stabile Dateisysteme, bei denen nicht laufend neue Bugs und Features eingebaut werden.
> Der Bug tritt bei einem Vanilla (Orginal Ungepatchtem !!) Linux Kernel auf.
Und? Fedora hat genau diesen Kernel für die Distribution ausgewählt. Hat irgendjemand behauptet, dass die Torwaldschen Kernel fix und fertig für die Distribution sind? - Nein, das Gegenteil ist der Fall: Die Distributoren sollen ihre Kernel testen, stabilisieren und erst dann ausliefern. Darüber gab's Diskussionen genug, so dass das inzwischen jeder wissen sollte. Nicht zuletzt stabilisiert Adrian Bunk den 2.6.16er Kernel für Endbenutzer. Der sollte inzwischen ausreichend gut getestet sein. Wenn Red-Hat meinet, was neueres einsetzen zu müssen, müssen sie halt auch entsprechend eigene Qualitätssicherung betreiben. Was meinst Du, was es für einen Aufschrei gäbe, wenn Windows-Vista RC1 Dateisysteme schrotten würde? Ohne ausreichende Qualitätssicherung wird's nie was mit Linux am Desktop.
>Wenn Red-Hat meinet, was neueres einsetzen zu müssen, müssen >sie halt auch entsprechend eigene Qualitätssicherung betreiben
Hast den Unterschied von Fedora und RH nicht geschnallt wie mir scheint.
Fedora ist ein Projekt das durch RH unterstützt wird. Fedora läuft mindestens für 6-9 Monate bevor Redhat daraus ein Enterprise Linux baut. Will heissen: Ein Fedora Core wird zuerst gebaut (mit ReleaseZyklen von 6 Monaten) und dann während einem knappen Jahr von uns Usern getestet (so gesehen sind wir Tester für kommende RHEL Releases).
Was meinst Du, was es für einen Aufschrei gäbe, wenn Windows-Vista RC1 Dateisysteme schrotten würde? Windows XP ohne Service Pack tut genau das bei Laufwerken größer als 128 GB.
Von Captn Difool am Mo, 9. Oktober 2006 um 12:50 #
Wie auch immer, für eine Distri auf der ein hochsicheres Profilinux aufsetzen soll, finde ich den Start doch recht holperig. Die hohe Anzahl sehr grober Schnitzer zeigt, daß man sich selbst einen hohen Termindruck gesetzt hat und es hinter den Türen sehr hektisch und chaotisch vorgehen muß, so wird keine Distri draus, der man vertrauen kann. Es war früher eigentlich nicht die vorgehensweise von RH, eine SuSE-mäßige Featuritis loszulawinen und statt dessen eher auf bewährte Versionen zu setzten, Features eben nur maß- und sinnvoll einzubringen. So erwarte ich bei FC6 eine recht große Anzahl nachträglicher Fixes, die man sich im Zeitlupentempo dann nachladen darf. FC5 konnte mich weder in Tempo noch Handling überzeugen, geschweige von der mageren Ausstattung. Mit FC6 scheint es sich nicht gerade freundlicher zu entwickeln. Soll diese ganze Aktionshektik nur dazu dienen, unbedingt VOR OpenSuSE 10.2 zu erscheinen? Letztere konnte mich eher überzeugen. Mit OpenSuSE 10.1 habe ich eine sehr stabile und schnellaufende Plattform, für ein Communitysystem angenehm gut.
Mit geht es hier nicht im Distri-Flaming, sondern ich stehe grundsätzlich jeder Distri offen, in den letzten vier Monaten habe ich beide getestet, da ich mich noch nicht entscheiden konnte. Auch das hier zitierte Debian ist nicht so toll, will man jenseits von "Stable" ein etwas aktuelleres System haben.
Und noch einer der den Sinn von Fedora noch nicht geschnallt hat.
Fedora IST KEIN Enterprise OS... sondern wird mal eins, wenns dann in einem knappen Jahr die Bugfixes durchlaufen hat, die es als Fedora während seinem Final-Core leben durchmacht.
Fedora IST Bleeding-Edge, stabilisiert wird es im Final-Zyklus (also von den Endusern).
Wobei ich persönlich die vergangenen FC3-5 nicht als Unstabil angesehen habe.
> Willst du Stabilität und getestete Driver/Kernel ? > -> Nimm ein Enterprise Linux
Laber doch nicht so nen Stuss! Nur weil sich ein paar Firmen ne Enterprise Version teuer bezahlen lassen, erwarte ich von einer kostenlosen Distri weiterhin in den *primären* und *grundlegenden* Bereichen ein *stabiles* Verhalten. Punkt.
Tja also Debian, Slackware und CentOS liefern Stabilität für umsonst. Was der Release-Zyklus mit der Stabilität zu tun hat ist mir unklar. Hängt wohl eher mit der Softwareauswahl zusammen, wenn Release A nur marginale Änderungen zu Release B hat dann dürfte der Effekt auf die Stabilität ebenso nur marginal sein. Natürlich kann man auch für teures Geld Windows, Linspire, etc kaufen. Ebenso kann man sich für umsonst fehlerhafte Software ziehen. Das Problem mit der Freiheit ist eben, dass sich da jeder so doof anstellen darf wie er will.
Also mal so als Aufkärung. Das Ziel von Fedora ist möglichst schnell die neusten Features in eine Distribution zu bringen. Fedora ist so was wie die Spielwiese für Redhat, damit RedHat ES eine höchst mögliche Stabilität hat, wenn ein neue Version rauskommt. Da aber Fedora so ein grosser Erfolg wurde, haben einige Leute neue Ansprüche an Fedora wie man ja sieht. :-) Fedora ist toll zum testen, auch sehr interessant für den Einsatz in nem Webenvironment, für alles DB mässige ist RHES da. Diese Strategie ist genial, denn im Gegensatz zu Hobby-Distributionen wie Gentoo/Debian/... kenne ich alle neuen Features von Redhat ES durch den Einsatz von Fedora auf den Testsystemen. Erst wenn etwas absolut stabil bei Fedora funktioniert kommt es in RHES. Bei den Hobby-Distributionen sind die neuen Features etwa so getestet wie bei Fedora und dazu hat man noch nicht mal Zertifizierungen, sprich wenn es bei grossen Systemen wie RAC dann ein Fehler gibt, den du nicht lösen kannst, kannst du dann die doofen Fragen des Chefs beantworten...
>Bezahlt dir dein Papi dein Auto. Von Beruf Sohn ? Von Beruf wohl unbezahlter Dauerpraktikant? Ich werde mich hüten für große Firmen den kostenlosen Deppen zu spielen und mir meine Daten zu schrödern nur damit die nächste Enterprise Edition von Redhat stabil läuft.
Nur das mit den ext3 oooopses sind nicht schön. Hoffentlich finden die das Problem noch. Soll aber nur bei hohem Load auftreten, und auch da nur in bestimmten Konfigurationen (also ein schwer reproduzierbarer Bug).
aus dem Blog von D. Jones: 2.6.18 - Should explode, and it does, I can reproduce it easily. 2.6.18 + Jan's patch - Shouldn't explode, and doesn't. (Or maybe I just didn't give the test long enough). 2.6.18 based Fedora kernel (which has Jan's patch) - Explodes horribly.
Nichts desto trotz, ich vertraue darauf, dass die Kernel-Leuts zusammen mit dem Fedora/RH Team das Problem ausfindig machen und es dann vernichten ^^ odrrr so
Zuviele Patches machen eben den Kernel kaputt. Wenn schon Patches dann sollte man sich wenigstens an die offiziellen Patchereien (-mm oder -ck) halten. Mir ist der Sinn dieser Patchorgien bei Fedora auch völlig unverständlich. "Nur bei hohem Load" ist sehr witzig, denn das bedeutet soviel wie "immer beim Kompilieren". Für Entwickler ist fedora damit wohl völlig unbrauchbar, selbst ein kleiner Compile wie abiword-cvs braucht ja recht lange und recht viel I/O.
2.4.18 (Vanilla Orginal Kernel) hat den Bug ! 2.4.18 mit dem "Jan'Patch" (der fixt einen Bug im 2.4.18 zu einem ähnlichen oder demselben Thema), klappt
Nicht zu vergessen -> Nicht wenige von den Leuten bei Fedora/Redhat arbeiten als Kernel-Maintainer.
Stichworte (FUD's ?): Patchorgien -> Referenzen dazu ? Hoher Load -> Kannst du das belegen ? Hoher I/O -> Kannst du das belegen (Benchmarks ?) ?
LOL, nö kompilieren braucht NIE hohen Load und I/O schon mal gar nicht, alles mein Fehler. Wenn beim kompilieren was die CPU-Last über 3% geht liegt es wohl daran, dass ich kein Fedora benutze und mein Kernel daher lauter Fehler enthält.
Wie wäre es denn zur Abwechslung mal mit Fakten, nachdem du dich immer so als Fachwissender hinstellst? Bisher kam nur heiße Luft. Kommt daher der Nick?
Aha 100% CPU sind also kein hoher Load? Schon mal mozilla compiliert? Und da ist bei der also kein hoher Load enstanden? Übrigens kann man im Make über die Option "-j" einstellen wieviele Prozesse parallel laufen. Auf normalen System single-core-system mit IDE würde ich allerdings nicht mehr als 3 machen.
Schon mal mozilla compiliert? ne, wer tut sowas freiweillig
Und da ist bei der also kein hoher Load enstanden? ich kenn den bug nicht (ist mir auch ziemlich egal, ist ne beta). ein normaler gcc prozess hat - glaube ich - nicht sonderlich viel IO. was ich nur sagen wollte, ich denke in ihren testsuits sind die high load tests was ganz anderes (web- oder fileserver mit vielen connections und prozessen).
> Nur das mit den ext3 oooopses sind nicht schön. Hoffentlich finden die das Problem noch.
Wo ist das Problem? Dann wählt man bei der Installation halt eines der anderen stabilen Dateisysteme wie Xfs oder ReiserFs3.6. Bei Suse wähle ich immer Xfs, hatte damit immer sehr gute Performance und noch nie Probleme. Wird doch bei Red-Hat auch einfach per Mausklick gehen, oder schränken die den Anwender immer noch ein?
> Bei Suse wähle ich immer Xfs, hatte damit immer sehr gute Performance und noch nie Probleme. Da bist du dir also sicher? Dann ließ mal das hier: http://oss.sgi.com/projects/xfs/faq.html#dir2
Ließ doch einfach mal den Link den ich gepostet habe, und dann kannst dir nochmal überlegen, WELCHES Dateisystem das betroffen hat - es war definitiv XFS!
-> Nimm ein Enterprise Linux
Willst du dumm rumlabern ?
-> Geh zu Heise
Willst du diskutieren ?
-> Probiers mit Argumenten
Ach, was fütter ich nen Troll *sfz* (Monday ?)
Was das mit den Patches von RH/Fedora zu tun hat ?
http://kernelslacker.livejournal.com/tag/ext3 belegt aber, dass es den vanilla-kernel betrifft. Dave Jones ist zwar RedHat-Entwickler, allerdings vertaue ich ihm schon so weit, dass er auch wirklich mit einem vanilla-2.6.18 getestet hat, wenn er das schreibt.
Da steht ja gross: "It isn't helping that it can only be reproduced on my box" vielleicht sollte man Linx auch mal lesen nicht nur posten
> noch nicht im Kernel selber sein.
*lol*
Wenn ein Vanilla-Kernel OOPS't dann ist es IMMER ein Problem des Kernels !
Und: Hör mal mit diesem "extra dolle patches märchen auf". Jede und ich meine JEDE Distri muss Vanilla Kernels patchen (wurde aber in diesem Topic auch schon angesprochen).
l=slackware-security&y=2004&m=slackware-security.541911
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0077
Thanks to Paul Starzetz for finding and researching this issue.
(* Security fix *)
patches/packages/kernel-ide-2.4.24-i486-2.tgz: Patched, recompiled.
(* Security fix *)
patches/packages/kernel-source-2.4.24-noarch-2.tgz: Patched the kernel
source with a fix for the mremap() problem from Solar Designer, and
updated the Speakup driver (not pre-applied).
(* Security fix *)
>8(
[PATCH] jbd: fix commit of ordered data buffers
Original commit code assumes, that when a buffer on BJ_SyncData list is
locked, it is being written to disk. But this is not true and hence it can
lead to a potential data loss on crash. Also the code didn't count with
the fact that journal_dirty_data() can steal buffers from committing
transaction and hence could write buffers that no longer belong to the
committing transaction. Finally it could possibly happen that we tried
writing out one buffer several times.
The patch below tries to solve these problems by a complete rewrite of the
data commit code. We go through buffers on t_sync_datalist, lock buffers
needing write out and store them in an array. Buffers are also immediately
refiled to BJ_Locked list or unfiled (if the write out is completed). When
the array is full or we have to block on buffer lock, we submit all
accumulated buffers for IO.
[suitable for 2.6.18.x around the 2.6.19-rc2 timeframe]
Das ist aus dem Changelog vom 2.6.19-rc1
Und jetzt überlegt mal jeder, warum es vielleicht doch nicht so toll ist, ext3 kontinuierlich zu erweitern und zu optimieren und warum das Reiser-Team will, dass an ReiserFS 3 *nur* Bugfixe vorgenommen werden sollen, während Erweiterungen, neue Features und Optimierungen in einem neuen Dateisystem stattfinden sollen.
Von ext3 gibt es mind. ein Dutzend verschiedene Hauptversionen, die nur abwärts (nicht aufwärts) zueinander kompatibel sind, aber alle den gleichen Namen, aber dafür unterschiedliche Bugs haben. Der immer identisch gehaltene Name suggeriert Stabilität, das ist marketingtechnisch für Red-Hat sehr vorteilhaft.
Zum Glück konnten sich die übrigen Kernelhacker zuletzt durchsetzen und haben verhindert, dass die neuesten, noch tiefer gehenden Änderungen ebenfalls im "stabilen" ext3 getestet werden. Nun gibt's ext4, aber allein schon der Versuch, ein neues Dateisystem unter dem alten Namen entwickeln zu wollen, sollte jedem, dem seine Daten lieb sind, zu Denken geben. Aber mit ReiserFs und Xfs gibt es ja leistungsfähige(re) und stabile Dateisysteme, bei denen nicht laufend neue Bugs und Features eingebaut werden.
dann lies dir das mal durch, besonders der Abschnitt über die Dateisysteme:
http://www.heise.de/open/artikel/71571
Gruß
Knut
Und? Fedora hat genau diesen Kernel für die Distribution ausgewählt. Hat irgendjemand behauptet, dass die Torwaldschen Kernel fix und fertig für die Distribution sind? - Nein, das Gegenteil ist der Fall: Die Distributoren sollen ihre Kernel testen, stabilisieren und erst dann ausliefern. Darüber gab's Diskussionen genug, so dass das inzwischen jeder wissen sollte. Nicht zuletzt stabilisiert Adrian Bunk den 2.6.16er Kernel für Endbenutzer. Der sollte inzwischen ausreichend gut getestet sein. Wenn Red-Hat meinet, was neueres einsetzen zu müssen, müssen sie halt auch entsprechend eigene Qualitätssicherung betreiben. Was meinst Du, was es für einen Aufschrei gäbe, wenn Windows-Vista RC1 Dateisysteme schrotten würde? Ohne ausreichende Qualitätssicherung wird's nie was mit Linux am Desktop.
>sie halt auch entsprechend eigene Qualitätssicherung betreiben
Hast den Unterschied von Fedora und RH nicht geschnallt wie mir scheint.
Fedora ist ein Projekt das durch RH unterstützt wird.
Fedora läuft mindestens für 6-9 Monate bevor Redhat daraus ein Enterprise Linux baut.
Will heissen: Ein Fedora Core wird zuerst gebaut (mit ReleaseZyklen von 6 Monaten) und dann während einem knappen Jahr von uns Usern getestet (so gesehen sind wir Tester für kommende RHEL Releases).
Windows XP ohne Service Pack tut genau das bei Laufwerken größer als 128 GB.
Mit geht es hier nicht im Distri-Flaming, sondern ich stehe grundsätzlich jeder Distri offen, in den letzten vier Monaten habe ich beide getestet, da ich mich noch nicht entscheiden konnte. Auch das hier zitierte Debian ist nicht so toll, will man jenseits von "Stable" ein etwas aktuelleres System haben.
Fedora IST KEIN Enterprise OS... sondern wird mal eins, wenns dann in einem knappen Jahr die Bugfixes durchlaufen hat, die es als Fedora während seinem Final-Core leben durchmacht.
Fedora IST Bleeding-Edge, stabilisiert wird es im Final-Zyklus (also von den Endusern).
Wobei ich persönlich die vergangenen FC3-5 nicht als Unstabil angesehen habe.
> -> Nimm ein Enterprise Linux
Laber doch nicht so nen Stuss! Nur weil sich ein paar Firmen ne Enterprise Version teuer bezahlen lassen, erwarte ich von einer kostenlosen Distri weiterhin in den *primären* und *grundlegenden* Bereichen ein *stabiles* Verhalten. Punkt.
>ein *stabiles* Verhalten.
Bezahlt dir dein Papi dein Auto. Von Beruf Sohn ?
Wenn ich das schon lese: "Ich erwarte von kostenloser Distri" *buah, da kommt mir das grosse wurgen*
PS: Und Enterprise Distris sind bestimmt länger getestet als jede Halbjahres Distri.
Aber das würde wohl zu weit gehen dir das zu erklären.
PPS: Oder vereinfacht. Eine Distri die alle 6Mt releast wird _kann_ gar nicht Bugfrei sein. Impossible !
Normalerweise gibts solche Flamewars ja nur bei Gentoo und Deblahm eeeh Debian Artikeln...
Natürlich kann man auch für teures Geld Windows, Linspire, etc kaufen. Ebenso kann man sich für umsonst fehlerhafte Software ziehen. Das Problem mit der Freiheit ist eben, dass sich da jeder so doof anstellen darf wie er will.
Fedora ist toll zum testen, auch sehr interessant für den Einsatz in nem Webenvironment, für alles DB mässige ist RHES da. Diese Strategie ist genial, denn im Gegensatz zu Hobby-Distributionen wie Gentoo/Debian/... kenne ich alle neuen Features von Redhat ES durch den Einsatz von Fedora auf den Testsystemen. Erst wenn etwas absolut stabil bei Fedora funktioniert kommt es in RHES. Bei den Hobby-Distributionen sind die neuen Features etwa so getestet wie bei Fedora und dazu hat man noch nicht mal Zertifizierungen, sprich wenn es bei grossen Systemen wie RAC dann ein Fehler gibt, den du nicht lösen kannst, kannst du dann die doofen Fragen des Chefs beantworten...
Von Beruf wohl unbezahlter Dauerpraktikant? Ich werde mich hüten für große Firmen den kostenlosen Deppen zu spielen und mir meine Daten zu schrödern nur damit die nächste Enterprise Edition von Redhat stabil läuft.
zu spät, tust du doch schon. Den ganzen Tag...
Nur das mit den ext3 oooopses sind nicht schön. Hoffentlich finden die das Problem noch.
Soll aber nur bei hohem Load auftreten, und auch da nur in bestimmten Konfigurationen (also ein schwer reproduzierbarer Bug).
aus dem Blog von D. Jones:
2.6.18 - Should explode, and it does, I can reproduce it easily.
2.6.18 + Jan's patch - Shouldn't explode, and doesn't. (Or maybe I just didn't give the test long enough).
2.6.18 based Fedora kernel (which has Jan's patch) - Explodes horribly.
Nichts desto trotz, ich vertraue darauf, dass die Kernel-Leuts zusammen mit dem Fedora/RH Team das Problem ausfindig machen und es dann vernichten ^^ odrrr so
2.4.18 (Vanilla Orginal Kernel) hat den Bug !
2.4.18 mit dem "Jan'Patch" (der fixt einen Bug im 2.4.18 zu einem ähnlichen oder demselben Thema), klappt
Nicht zu vergessen -> Nicht wenige von den Leuten bei Fedora/Redhat arbeiten als Kernel-Maintainer.
Stichworte (FUD's ?):
Patchorgien -> Referenzen dazu ?
Hoher Load -> Kannst du das belegen ?
Hoher I/O -> Kannst du das belegen (Benchmarks ?) ?
Übrigens kann man im Make über die Option "-j" einstellen wieviele Prozesse parallel laufen. Auf normalen System single-core-system mit IDE würde ich allerdings nicht mehr als 3 machen.
ne, wer tut sowas freiweillig
Und da ist bei der also kein hoher Load enstanden?
ich kenn den bug nicht (ist mir auch ziemlich egal, ist ne beta). ein normaler gcc prozess hat - glaube ich - nicht sonderlich viel IO. was ich nur sagen wollte, ich denke in ihren testsuits sind die high load tests was ganz anderes (web- oder fileserver mit vielen connections und prozessen).
Wo ist das Problem? Dann wählt man bei der Installation halt eines der anderen stabilen Dateisysteme wie Xfs oder ReiserFs3.6. Bei Suse wähle ich immer Xfs, hatte damit immer sehr gute Performance und noch nie Probleme. Wird doch bei Red-Hat auch einfach per Mausklick gehen, oder schränken die den Anwender immer noch ein?
Da bist du dir also sicher? Dann ließ mal das hier:
http://oss.sgi.com/projects/xfs/faq.html#dir2
Mit Kernel 2.6.17 würde ich XFS nicht benutzen!!!
Reiser FS?
Junge, geh heim zu Mami.
Und versuch bitte nie wieder der Menschheit einen Tipp zu geben.