Comme prévu le 2.4.15 contient ext3, mais aussi des mises à jour de drivers, de l'usb, de nfs, de la VM et tout le toutim :)
Voici le README trouvé sur kernel.org à propos du 2.5.0 :
"Linux-2.5.0 is exactly the same as 2.4.15, except for a version number change. Subsequent releases diverge, with Marcelo Tosatti maintaining the stable 2.4.x kernels, while the 2.5.x kernels are for development work."
Comprenez que le 2.5.0 est identique au 2.4.15 au numero de version près. A partir d'aujourd'hui les 2 branches divergent. Marcelo Tosatti se chargera désormais de maintenir les 2.4 et les 2.5 sont des versions de développement.
Aller plus loin
- ChangeLog 2.4.15 (2 clics)
- v2.5 on kernel.org (2 clics)
# et voila la liste des miroirs
Posté par Christophe Fergeau . Évalué à 1.
http://www.kernel.org/mirrors/(...)
D'habitude j'utilise ftp://ftp.fr.kernel.org(...) , mais il a pas l'air d'etre a jour pour le moment
[^] # Re: et voila la liste des miroirs
Posté par kalahann . Évalué à 1.
Hop, les liens direct vers les noyaux sur ce serveur:
patch-2.4.15: ftp://ftp.tengu-easynet-fr.lkams.kernel.org/pub/linux/kernel/v2.4/(...)
linux-2.4.15: ftp://ftp.tengu-easynet-fr.lkams.kernel.org/pub/linux/kernel/v2.4/(...)
2.5.0: ftp://ftp.tengu-easynet-fr.lkams.kernel.org/pub/linux/kernel/v2.5/(...)
Si vous avez déjà un 2.4.13 ou .14 , utilisez les patch plutôt que les noyaux, ça épargne les miroirs et ça va plus vite à télécharger!
Question: Que pensent les personnes qui en ont utilisés, des noyaux de développement? est-ce suffisamment stable et fiable pour une station personnelle?
Je comptais passer en 2.5 (jamais sur la *toute* dernière version du noyau évidemment, je tiens pas à me faire corrompre mes disques) mais j'avoue que j'hésite un peu...
[^] # Re: et voila la liste des miroirs
Posté par thomas . Évalué à 1.
sinon, si c'est juste pour se dire qu'on a le dernier-noyau-de-la-mort-qui-roulaize-a-donf, alors je ne vois vraiment pas pourquoi ...
finalement mon conseil : pour une station personnelle, reste en x.y.z avec y pair ... sauf si tu es toi-meme developer/tester du noyau (ou que le support pour ta toute dernier carte graphique 512Mo de DDR/ - 400 Milliard de pixels/sec ne soit present que dans un noyau de dev...)
[^] # Re: et voila la liste des miroirs
Posté par Anonyme . Évalué à 1.
Pourquoi ? Ben parce que c'est joli comme numéro de version.
J'attendais que le 2.4.15 sorte pour l'installer ; il se trouve qu'on le trouve aussi sous la forme d'un 2.5.0, quelle aubaine :)
Et quand les noyaux 2.4 suivants existeront, je piocherai bien évidemment dedans ;)
[^] # Re: et voila la liste des miroirs
Posté par wismerhill . Évalué à 1.
[^] # Re: et voila la liste des miroirs
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
Mais tu peux toujours en faire un, ça ne fait pas de mal...
Par contre, pour patcher ton noyau, il suffit de taper la commande suivante :
patch -p1 < /chemin/du/path.x.y
Le système de patch fonctionne très bien...
Ainsi j'ai une archive du 2.4.5 que j'ai patché à chaque nouvelle version et aucun problème... (je sais pas s'il y a une limite).
[^] # Re: et voila la liste des miroirs
Posté par woof . Évalué à 1.
[^] # Re: et voila la liste des miroirs
Posté par matiasf . Évalué à 1.
30 personnes en voté pour ton poste :
* 11 (37%) pensent qu'il est pertinent de rappeler l'adresse des mirrors de kernel.org qui est assez chargé.
* 19 (63%) personnes en ont rein à foutre.
Conclusions :
* La news est excellente car elle fait pas chier la majorité avec une url sur les mirrors dont elle n'a rien à foutre.
* Modérateurs, si on vous propose une news avec une url sur la liste des mirrors, virer cette url.
* Utilisateurs de linuxfr, évitez de poster une url sur la liste des mirrors, c'est mauvais pour vos XP.
[^] # Re: et voila la liste des miroirs
Posté par Robert Palmer (site web personnel) . Évalué à 0.
Un commentaire ne VOUS intéresse pas ? Passez votre chemin et utilisez vos votes pour scorer [+] les commentaires qui en valent la peine.
Le commentaire de teuf apporte une info, certes connue et pas révolutionnaire mais elle a le mérite de palier un manquement de la news. Pas de quoi déclancher une telle avalanche de votes.
En plus, il propose un lien alternatif.
Beaucoup de bruit pour pas grand chose...
-1 parce que c'est pas une news sur les XP
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
# ext3
Posté par matiasf . Évalué à 1.
Depuis les sources Linux il est possible de faire un rpm :
$ cd /usr/src/linux-2.4*
$ make rpm
ou
$make spec
puis faire un rpm -bb kernel.spec
PS : c'est une procédure très grossière...
[^] # Enfin journalisé !
Posté par Henri . Évalué à 1.
Du coup, ce serait le moment de lancer un bon débat : quel fs ? Les candidats sont nombreux : ext3, reiserfs, xfs et jfs principalement (mais il doit y en avoir d'autres, par exemple AtheOS a le sein). Ext3 a un avantage de transition évident (transformation ext2 <-> ext3), mais est-ce suffisant. Des benchs (par exemple http://www.namesys.com/benchmarks/benchmark-results.html(...)) sont-ils aussi suffisants ?
Car tout ce que je veux, c'est ne jamais perdre mes données ; ceux qui ont essuyé les plâtres de reiser connaissent la chanson !
[^] # Re: Enfin journalisé !
Posté par matiasf . Évalué à 1.
En gros c'est la même chose. Les performances sont très proche.
Pour mon usage perso avoir un système journalisé n'apporte partiquement rien. De plus les systèmes de fichier journalisé sont sure avec SCSI (ordre d'écriture garanti) et ne supporte pas les coupures de courant. Bref, c'est uniquement pour les plantages noyau (le reset hard est supporté). Ces infos sont dans le README de la 7.2.
Pour une utilisation au boulot:
station de travail : ext3 n'apporte rien.
serveur : nos serveur (qui sont de petits serveurs...) ne plante pas. Donc très peut de gain.
Conclusion ext2/ext3 :
ext3 aporte la journalisation sans surcoût. Alors pourquoi s'en priver .
[^] # Re: Enfin journalisé !
Posté par void . Évalué à 1.
[^] # Re: Enfin journalisé !
Posté par Aurélien Jarno (site web personnel) . Évalué à 1.
Tu devrais dire n'ont pas encore planté, car ca va bien arriver un jour que ca viennent de l'OS ou de l'exterieur (panne de courant, onduleur...). Dans ce cas tu serais peut-être content d'avoir un système de fichiers journalisé !
[^] # Re: Enfin journalisé !
Posté par matiasf . Évalué à 1.
- Je préfère un système très fiable sans système de fichier journalisé qu'un système moyennement fiable avec système de fichier journalisé. Par exemple, un système de fichier journalisé sous windows pour des postes de travail, c'est super cool. Un système de fichier journalisé sous Linux (Qui pour des raison technique hardware, ne peut supporter les coupures de courant ni les disques IDEs, idem avec Windows) est moins interressant pour un usage classique.
Après si du fait des tests noyau, que tu as des disque SCSI, un serveur qui doit être disponible 24h/24 7j/7 365j/ans alors dans ce cas un système de fichier journalisé est super cool moins pour un système hyper fiable.
PS :
Pour les fautes d'orthographe, je te laisse corriger...
[^] # Re: Enfin journalisé !
Posté par Christophe BAEGERT . Évalué à 1.
Les systèmes de fichiers journalisés ne marchent pas avec les coupures EDF ? Seulement avec les crash kernels ? Ah ben ca doit etre hyper utile alors vu la fréquence des kernel panic !!!
En plus tu dis que c'est dans la README de la 7.2, j'ai vérifié y'a rien !!!
Arrete de fumer !!! -> -1 (t'as de la chance qu'on ne puisse pas voter en dessous)
[^] # Re: Enfin journalisé !
Posté par matiasf . Évalué à 1.
Tu as raison, c'est dans le "RELEASE-NOTES".
REALSE-NOTES :
ftp://ftp.free.fr/pub/Distributions_Linux/RedHat/redhat/redhat-7.2(...)
Plus une copie partielle du fichier :
> Veuillez prendre note que les fichiers journaux aussi peuvent être
> endommagés en cas de panne d'électricité. Lorsqu'un système est privé
> de courant, le comportement de ce système est indéterminé. Exemple : le
> contenu de la mémoire peut se dégrader (devenir corrompu de façon
> aléatoire) car il est copié sur le disque dur exécutant les derniers
> souffles d'énergie. Cette situation est complètement différente de la
> séquence d'événements définie qu'est l'arrêt du système en appuyant sur
> le bouton « réinitialiser » lorsque le système est en cours d'exécution.
> En outre, les disques durs IDE n'offrent pas toutes les garanties d'ordre
> d'écriture que les disques SCSI offrent.
Maintenant t'es libre de faire comme les autres et de dire que les systèmes de fichier journalisé c'est top génial pour ton PC personnel sans onduleur avec disque ide qui passe par un controleur avec 16 Mo de cache et un noyau 2.5.x (x > 0).
J'ai une RedHat 7.2 ou boulot avec ext3 depuis 1 moi. Mon pc avait des problèmes avec les nappes IDE (c'est un pc de dev, donc du IDE c'est nettement suffisant). A cause de ce problème, le noyau a fait plusieurs panic/freeze (les données qui venait du swap je pense). A chaque reboot le fsck n'était pas complet mais rapide (c'est le "plus" d'ext3). J'ai fait des fsck forcés (-f) et il restait des erreurs ! C'est normal. Le noyau (et ext3) croit avoir écrit correctement sur le disque, hors ce n'est pas le cas. Une foi le problème des nappes fixé, pas de plantage et donc peu d'interrêt d'ext3.
Je me répète, mais un système de fichier journalisé c'est pas très intéressant pour un usage courant (sauf peut-être sous Windows :-) ).
[^] # Re: Enfin journalisé !
Posté par Antoine Labour . Évalué à 5.
Tout le principe des fichiers journalisés repose sur le fait que sur un disque dur, l'écriture d'un secteur est atomique. Tous les disques dur qui ont moins de 5 ans font ça, en cas de coupure de courant, ils écrivent le secteur qu'ils étaient en train de faire (ils gardent toujours un poil d'énergie) et s'arrêtent (ça peut être plus d'un secteur).
Donc quand tu demande l'écriture d'un secteur, soit elle est effectuée complètement, soit elle ne l'est pas. Ensuite, le principe général, c'est d'avoir un journal d'opérations à effectuer, et une table de validité de ces opérations. Quand tu veux effectuer une série d'opérations, elles sont toutes entrées dans la table, puis elles sont toutes marquées valides (à effectuer), de manière atomique. Puis elles sont appliquées, puis tout marquées invalides, de manière atomique encore. Du coup, en fonction du point ou tu t'arrêtes/plante,
- soit les opérations ne sont pas toutes écrites dans le journal, alors elles ne sont pas marquées valides. au redémarrage, tu as perdu les opérations, mais ton système est toujours cohérent
- soit les opérations sont toutes écrites, et toutes marquées valides. Au redémarrage, tu les effectue. Si elles avaient déjà été effectuées toutes ou en partie, c'est pas grave... Elles sont juste faites 2 fois. Au final, ton système est toujours cohérent
- soit les opérations avaient été effectuées, et marquées invalides, dans ce cas, elles sont ignorées au redémarage. Ton système était cohérent au crash, et il le reste.
Je ne sais pas si je suis clair, mais il y avait eu un article sur les fichiers journalisés dans un LHFM il y a environ un an, qui expliquait bien cela.
Au final, je dirais que si ext3 ne fait pas ça, eh bien en tout cas ReiserFS le fait, lui.
[^] # Re: Enfin journalisé !
Posté par matiasf . Évalué à 1.
Tu crois que RedHat va dire du "mal" ext3 pour se faire plaisir?
C'est comme si Microsoft annoncais des bugs dans Windows qui n'existent pas.
> Tout le principe des fichiers journalisés repose ...
> ...
Globalement, tout ce que tu dis est juste ! C'est le même principe de transaction que les bases de données qui est atonique :-> .
Tu parles de coupure de courant sur les disques dures. Hors RedHat parle de coupure de courant sur la carte mère. Dans ce cas, la mémoire vive peut être corrompue alors que l'os envois la demande d'écrire (les données peuvent également être corrompu au niveau du controleur IDE). Les disques font correctement leur travail mais écrivent des données corrompues. Bien sure, si les disques dures tombent avant la carte-mère il n'y a pas de problème.
Il faut bien noté que c'est un problème de hardware auquel Linux (ou windows ou Solaris ou ...) ne peut rien !
Imaginons une solution (je ne connais rien à l'électronique).
Sur coupure de courant une capa permet à ma CM de tourner encore 1 seconde.
Un système en amont de la carte mère controle l'arrivé du courant.
S'il détecte un problème sur l'arrivé du courant :
- 0,5 secondes après, fait un reset hard (d'après RedHat ext3 le supporte) si alimentation non stable.
- 0,9 secondes après, arrêt de la carte mère jusqu'au retour d'une alimentation stable.
Enfin, l'autre problème soulevé par RedHat est que les disques IDE peuvent réorganiser l'ordre d'écriture. Ceci afin de limiter les déplacements du bras du disque dure. l'OS dans ce cas ne peut rien. L'os ne connait pas la géométrie du disque : en effet sur les disques moderne, les informations de géométrie retournées ne correspondent pas toujours à l'organisation réelle. Donc l'os ne peut limiter les déplacements de bras aussi finement que peut le faire le controleur du disque qui lui connait la géométrie réelle du disque. Ne parlons même pas des cartes raid qui font croire à l'os qu'il n'y a qu'un disque dur alors qu'il y en a plusieurs...
Par contre SCSI garanti l'ordre d'écriture et fait l'impasse sur l'optimisation des déplacements des bras.
Avec SCSI :
- l'OS demande :
---- écriture donnée
---- validation donnée
- le disque SCSI fait :
---- écriture donnée
---- validation donnée (atonique)
Avec IDE :
- l'OS demande :
---- écriture donnée
---- validation donnée
- le disque IDE PEUT FAIRE :
---- validation donnée (atonque)
---- écriture donnée. S'il y a coupure de courant avant écriture des données tu as un journal qui indique des données validées alors qu'elles n'ont pas été écrites !
[^] # Re: Enfin journalisé !
Posté par VERMEEREN Sebastien . Évalué à 1.
[^] # Re: Enfin journalisé !
Posté par matiasf . Évalué à 1.
C'est l'idéal. mais un onduleur c'est cher.
Je parle d'un truc à 5 francs et non 1000.
Et linux ne s'arrête pas en 0,5 seconde...
[^] # Re: Enfin journalisé !
Posté par VERMEEREN Sebastien . Évalué à 1.
[^] # Re: Enfin journalisé !
Posté par Christophe BAEGERT . Évalué à 1.
Si t'as 100Go de données à checker avant de redémarrer, quoiqu'il arrive il vaut mieux du journalisé, et perdre 2 ou 3 octets est mineur dans ce cas, de toute facon ca arrive tous les jours sur tous les disques avec ou sans crash.
[^] # Re: Enfin journalisé !
Posté par matiasf . Évalué à 1.
Dans un post plus haut je donnais mon avis sur ext2/ext3 de mon point de vu utilisateur :
> Conclusion ext2/ext3 :
> ext3 aporte la journalisation sans surcoût. Alors pourquoi s'en priver.
[^] # Re: Enfin journalisé !
Posté par Nÿco (site web personnel) . Évalué à 1.
Il est toujours urgent d'attendre... à défaut de tester/débugger...
[^] # Re: Enfin journalisé !
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
D'après ce que j'avais compris ext3 est compatible ext2. C'est ce qui m'avait décidé à changer et depuis je n'ai pas eu le moindre problème.
[^] # Re: Enfin journalisé !
Posté par matiasf . Évalué à 1.
C'est un peut "naze" comme remarque.
Par exemple, tu peux utiliser fsck fournie avec, par exemple, une redhat 6.2 sur un ext3. Dans ce cas, le journal peut être supprimé et tu ne peux plus monté la partition en ext3.Il faut recréer le journal avec tune2fs. Et si tu n'as pas une version de tune2fs qui permet l'ajout du journal, tu supprimes la journalisation avec l'option "-O". Tu reboot sous ta RH7.2 (par exemple) et tu réactives la journalisation avec tune2fs.
Bref, je comprend pas ta remarque...
# XFS roulaize à bloc
Posté par poil oq . Évalué à 1.
[^] # Re: XFS roulaize à bloc
Posté par Cédric Delfosse . Évalué à 1.
http://kt.zork.net/kernel-traffic/kt20011001_135.html#5(...)
[^] # Re: XFS roulaize à bloc
Posté par Serge Rossi (site web personnel) . Évalué à 1.
http://www-106.ibm.com/developerworks/linux/library/l-fs7/(...)
Pour résumer : journaling des metadata ET des données plus physical journaling contre metadata seulement et logical journaling pour les autres.
[^] # Re: XFS roulaize à bloc
Posté par Cédric Delfosse . Évalué à 1.
LinuX avec X et XFS, ça le fait non ?
[^] # Re: XFS roulaize à bloc
Posté par GCN (site web personnel) . Évalué à 1.
[^] # Re: XFS roulaize à bloc
Posté par bmc . Évalué à 1.
-1
# Ext3 !!!
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Ext3 est maintenant intégré en standard !
Rappel pour les ceusses qui n'auraient pas suivi : ext3 est un système de fichiers journalisé, c'est à dire bien plus résistant aux coupures de courant intempestives. Dans ce cas, non seulement ext3 assure une meilleure intégrité des données sur le disque mais il supprime le besoin de faire un fsck au redémarrage suivant. Au remontage du FS, le noyau a juste besoin de "rejouer" le journal sur le disque pour le restaurer en bon état.
A noter aussi que, contrairement aux autres FS journalisés (ReiserFS, JFS, XFS), ext3 peut journaliser non seulement les modifications sur les métadonnées mais aussi sur les données elles mêmes.
Autre avantage non négligeable : la migration.
Avec une version récente de e2fsprogs (1.20 au moins et non 1.19 comme c'est marqué dans Documentation/Changes), il suffit de taper tune2fs -j /dev/partition (hda1, sda1...) pour créer un journal sur le filesystem ext2. Pas besoin de le démonter pour ça.
Au remontage suivant du disque, il sera monté en ext3 (penser à modifier /etc/fstab en conséquence).
[^] # Re: Ext3 !!!
Posté par kadreg . Évalué à 1.
Une donnée, je vois a peu près ce que c'est, mais qu'es-ce qu'une meta-donnée ?
[^] # Re: Ext3 !!!
Posté par kalahann . Évalué à 1.
[^] # reiser et meta
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 1.
Heureusement que j'avais un backup, mais a reiser, je n'y touche plus avant un bon moment
[^] # Re: reiser et meta
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
L'avantage principal de reiser n'est pas la sécurité des données, mais les performances (inégalables pour la gestion des petits fichiers). Associé à des backups réguliers, c'est une bonne solution.
[^] # Re: reiser et meta
Posté par kalahann . Évalué à 1.
Chez moi j'ai mis toutes mes partoches (sauf / et /boot, je suis pas malade) en reiserfs par-dessus du raid software ide, pour avoir des bonnes perf et des données sûres...
Je sais qu' il y avait eu pas mal de pb de corruption liés à reiserfs au début, mais maintenant ça marche, ou pas?
[^] # Re: reiser et meta
Posté par Robert Palmer (site web personnel) . Évalué à 1.
Par exemple dans le fichier chap-secret il n'y avait plus mon identifiant et mot de passe pour la connexion Internet mais un fichier de conf quelconque de KDE. Pire, j'ai retrouvé par hasard la totalité de /etc/passwd dans un log de XFree...
Ce qui est bizarre, c'est que j'ai ces erreurs malgré la synchronisation d'urgence que je fais grâce aux Magic SysRQ (alt+impr. ecran+S). Ce n'est pas pris en charge par reiserfsd ?
ReiserFS semble donc avoir du mal avec les metadata.
<pub>
Depuis, j'ai adopté ext3, et ma vie a changé. Je n'ai plus constaté de corruptions de ce genre (c'est vrai que j'ai résolu mes problèmes de plantage aussi)</pub>
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Re: reiser et meta
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
J'ai eu la même chose avec ext2, et pas dans sa période de développement... Je pense que la plupart des problèmes de reiserfs ont été résolus, ce qui nous amène à un niveau de sûreté égal ou supérieur à celui d'ext2.
Le seul truc vraiment emmerdant que j'ai eu avec reiserfs était du à un bug qui fut corrigé depuis, et qui empêchait l'effacement de certains répertoires.
Maintenant, par rapport à XFS, JFS ou ext3, je pense que la sécurité est moindre.
[^] # Re: reiser et meta
Posté par Robert Palmer (site web personnel) . Évalué à 1.
Je ne pense pas que la version de reiserfs de ce noyau soit si veille que ça !
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Re: reiser et meta
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Mais pas longtemps après, je me suis retrouvé avec /etc/X11/prefdm dans /usr/share/apps/kdm/kdmrc :(
Moi qui voulait accuser Mdk, ça viendrait donc de ReiserFS. Aîe, je suis en ReiserFS partout :(
Ce WE => migration vers Ext3
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: reiser et meta
Posté par Johann Deneux . Évalué à 1.
J'avais fait l'operation de passer d'ext2 en reiserFS, je vais la reiterer pour aller de reiserFS en ext3.
[^] # Re: reiser et meta
Posté par matiasf . Évalué à 1.
Heureusement qu'il y a RedHat, Debian (liste non complète !) pour ne pas sauter sur tout ce qui bouge et faire la course à la dernière version de noyau (surtout pour les systèmes de fichier).
J'ai parfois l'impression que les "Linuxiens" sont aussi c.. que les windowsiens (pas peur de suicider mes XP !).
[^] # Re: reiser et meta
Posté par Anonyme . Évalué à 1.
Ca tourne très bien ; je n'ai eu aucun des problèmes dont vous parlez tous, ni d'autres.
Bref, pour moi, Reiserfs, ça le fait...
Après, je pense que c'est une question de choix et d'expérience personnelle. J'avoue que le concept de reiserfs me séduisait, alors je l'ai essayé ; comme il marchait bien, je l'ai gardé.
[^] # Re: reiser et meta
Posté par Johann Deneux . Évalué à 1.
A partir du moment ou ta machine ne se plante pas, reiserFS a sans doute ses avantages (rapidite ?).
Mais a ceux qui comme moi veulent eviter de perdre leurs fichiers a cause de coupures/plantages, reiserFS n'est apparemment pas l'ideal.
[^] # Re: reiser et meta
Posté par Marc . Évalué à 1.
Bon, il faut relativiser car le coup de construire sa distrib avec une version CVS de gcc, c'est mille fois pire.
[^] # Re: reiser et meta
Posté par matiasf . Évalué à 1.
Seulement un errata sur le préprocesseur (cpp).
Enfin, RedHat est beaucoup impliqué dans gcc principalement après le rachat de cygnus et peuvent se permettre ce chois "étrange".
Dailleur Mandrake a suivi RedHat :-) .
Et si Linux ne se compilait pas avec gcc 2.96-RH c'est car cette version de gcc est plus stricte que les anciennes et révélait des bugs dans Linux.
Et non l'inverse. Ainsi, gcc V3 qui est supérieur à gcc 2.96 rencontre les même problèmes de compatibilité avec Linux :-) .
Mais le pire est d'avoir sorti un gcc 2.96 alors que la vers 2.96 n'était pas sortie par www.gcc.org.
[^] # Comme quoi...
Posté par bmc . Évalué à 1.
[^] # Re: Ext3 !!!
Posté par Bertrand Vieille . Évalué à 1.
Le gros avantage du ext3, comparé aux autres FS journalisés, est que l'on peut monter une partition ext3 en ext2, on perd l avantage du systeme journalise, mais pour reparer un linux en vrille c'est pratique.
[^] # Re: Ext3 !!!
Posté par nabucu . Évalué à 1.
on spécifie simplement auto de manière à pouvoir redémaré en cas de besoins sur un vieux kernel ne suportant pas le ext3.
Si on à ext3 en dur dans le fstab. il n'y comprend rien. avec seuelement auto, il se débrouille pour remonter le tout en ext2.
En espérant ne pas m'être trompé...
[^] # Re: Ext3 !!!
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
Et moi je le déconseille.
En effet mkinitrd (au moins la version 3.1.6-mdk de Mandrake) ne mettra pas le module ext3 dans initrd si il ne trouve pas ext3 explicitement comme filesystem de /.
Ca provoque un beau "no init found. Kernel Panic" au reboot après la mise à jour du noyau :(
[^] # Re: Ext3 !!!
Posté par Anonyme . Évalué à 1.
Au détriment évident de l'espace disque et des performances...
Par contre, ça n'empêche pas de perdre du travail, mais ça évite de se retrouver avec des fichiers qui contiennent des informations éronnées.
[^] # Re: Ext3 !!!
Posté par schyzomarijks . Évalué à 1.
Faux, si au cours d'une transaction ton application fait deux écritures et que le pc plante avant que la seconde est été validée. Le système de fichier retournera au dernier état cohérent du fichier, cad avec une transaction à moitié effectué.
Par contre, le fichier sera toujours lisible et les données pourront être éventuellement reparés.
Voilà voilà.
[^] # Re: Ext3 !!!
Posté par Anonyme . Évalué à 1.
[^] # Re: Ext3 !!!
Posté par schyzomarijks . Évalué à 1.
Moi j'avais compris cette phrase dans le sens informations de l'utilisateur.
un texte ou une image qui après redémarrage ne seront pas forcément valident par l'application cliente mais qui est poutant dans un état correct vis à vis du système de fichier.
Disons que mon commentaire était un petit complément d'information.
[^] # Re: Ext3 !!!
Posté par syntaxerror . Évalué à 1.
l'excellent doc de Qing Liu:
http://www.linuxfr-france.org.invalid/article/sys/ext3fs/(...)
[^] # Re: Ext3 !!!
Posté par matiasf . Évalué à 1.
Les lecteurs de linuxfr aime les systèmes de fichier performant. La popularité de ReiserFS sur linuxfr est significative (çà change avec ext3).
Hors la sécurité c'est plus important.
Avec ext3 et avec les paramètrages par défaut, les données sont journalisé contrairement à ReiserFS. Avec ReiserFS lors d'un reboot violent, il indique aucun problème au niveau système de fichier mais les données peuvent être corrompues.
Pour les aspects performance, si quelqu'un fait un bench entre ext3 et ReiserFS il faut qu'il désactive la journalisation des données d'ext3 (mode writeback) pour faire une comparaison juste.
Enfin, avec ext3, le journal peut être mis sur un autre disque physique ce qui peut encore améliorer les performances.
[^] # Re: Ext3 !!!
Posté par kadreg . Évalué à 1.
Je ne suis pas d'accord. Tester pour le plaisir de tester, je trouve pas ça interressant.
Il faut comparer des solutions complètes. Personne n'utiliserai un ext3 en journalisation meta seule. C'est un tout.
Un bench, c'est UNE partie de ce qui rentre en compte dans un choix, mais c'est très loin d'être le seul. Vire les systèmes de protection dans tous les softs, il vont largement plus vite, mais qui voudrais d'un système qui tient pas 10 minutes ?
[^] # Re: Ext3 !!!
Posté par matiasf . Évalué à 1.
Je dis çà que il y a 3 ou 4 ans, MySQL était souvent livré avec fsync() désactivé (ce qui est abominable pour la sécurité des données). Et lorsqu'il y avait une comparaison être PostgreSQL et MySQL, MySQL était évidament plus rapide. Alors que sous PostgreSQL on peut aussi désactivé l'appel à fsync() (à évité bien évidament...).
Il faut comparer ce qui est comparable ou être très claire dans ce qui est comparé. exemple :
ext2 : pas de journalisation
ext3 conf 1 : journalisation data/metadata
ext3 conf 2 : journalisation metadata
ReiserFS : journalisation metadata
[^] # Re: Ext3 !!!
Posté par Gaël Le Mignot . Évalué à 1.
Ext3 possède trois modes de fonctionnement:
data=writeback => journalisation des méta-données
data=journal => journalisation des données et des méta-données
data=ordered => mode par défaut: seules les méta-données sont journalisées, mais le système n'écrit les méta-données que lorsque les données correspondantes ont déjà été écrites; le filesystem reste donc toujours dans un état cohérent.
Les différents modes d'ext3 sont expliqués en détail sur http://www-106.ibm.com/developerworks/linux/library/l-fs7/(...) ainsi que sur http://www.redhat.com/support/wpapers/redhat/ext3/index.html(...)
# Waouh !! Je tourne en 2.5 !!
Posté par Thibauld Favre (site web personnel) . Évalué à 1.
bon ok -1
sans rancune
thibs
# Champagne !!!
Posté par vrm (site web personnel) . Évalué à 1.
# Openwall
Posté par Fabien . Évalué à 1.
Maintenant j'attends le patch kernel Openwall, quelqu'un saurait où il en est ?
http://www.openwall.com(...) (aucunes infos sur le site à part qu'ils attendaient le 2.4.15 donc ??? )
Et si y en a qui l'ont utilisé avec les anciennes versions du kernel, pourraient ils nous faire profiter de leur expérience sur ce patch ?
[^] # Re: Openwall
Posté par Mario Gaucher . Évalué à 1.
une patch pour le kernel 2.4.15 basée sur Openwall et plein d'autres choses aussi...
# Petite erreur dans la boiboite !
Posté par Nÿco (site web personnel) . Évalué à 1.
Le kernel Alan Cox n'est pas nommé "pre", c'est du Linus, ça...
Il faudra donc corriger la boiboite, n'est-ce pas mêssieux daCode ?
Il y aura les patches 2.4.XX(mt), le 2.5.YY(lt) et le 2.5.ZZac, non ?
(mt = Marcelo Tosatti - lt = Linus Torvalds - ac = Alan Cox)
[^] # Re: Petite erreur dans la boiboite !
Posté par Netsabes . Évalué à 1.
Alan Cox avait annoncé récemment (le post doit encore être sur la home d'Advogato) qu'il lachait un peu les kernels pendant un moment, si je me souviens bien.
# 2.4.15 inutilisables...
Posté par Fabien . Évalué à 1.
"I'm seeing this on sparc as well. This is because show_trace_task() is
called from kernel/sched.c, and is only implemented in i386/kernel/. This
means that other architectures that don't implement it will break. The
sparc tree is equally broken too."
# 2.4.15-greased-turkey
Posté par Stéphen JANNIN . Évalué à 1.
[^] # Re: 2.4.15-greased-turkey
Posté par Aurélien Jarno (site web personnel) . Évalué à 1.
[^] # Re: 2.4.15-greased-turkey
Posté par kadreg . Évalué à 1.
Pour info, c'est défini là :
linux/include/linux/version.h in 2.4.15:
#define UTS_RELEASE "2.4.15-greased-turkey"
#define LINUX_VERSION_CODE 132111
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
[^] # Re: 2.4.15-greased-turkey
Posté par kadreg . Évalué à 1.
[^] # Re: 2.4.15-greased-turkey
Posté par matiasf . Évalué à 1.
version.h est un fichier généré par un Makefile (avec "make dep" par exemple).
D'ailleur, il sera supprimé par un "make mrproper" !
[^] # Re: 2.4.15-greased-turkey
Posté par kadreg . Évalué à 1.
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0111.2/1610.html(...)
[^] # Re: 2.4.15-greased-turkey
Posté par matiasf . Évalué à 1.
Mais fait un :
$ vi /usr/src/linux/Makefile
au début il y a un truc du style :
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 9
EXTRAVERSION = -13custom
KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
mais à "" EXTRAVERSION et regarde si çà corrige le problème.
# Le noyau aujourd'hui et demain...
Posté par Samuel Pajilewski . Évalué à 1.
J'ai fait un essai avec le noyau 2.4.13 (il se fait deja vieux) et y a plus de plantage quand on lit du Divx, y a plus de swapping monstrueux, par contre y a encore du boulot niveau performance (c'est bizard, de temps en temps y a des ralentissements genant, style je joue a Quake 3 et pendant une demi seconde ça se fixe, cela pendant 1 minute, et apres tout retourne dans l'ordre...)
Je vais essayer le noyau 2.4.15.
Ce qui me plait, c'est la possibilité de supporter le hot plug PCI (ça devenait franchement necessaire, surtout avec certains portables...)
Bien sur, c'est pas parce qu'on a le noyau 2.4.15 que tout va s'integrer facilement comme sous Windows 98 : pour integrer un periph usb, il faudra encore ouvrir une console pour integrer les modules, en esperant les avoir integres lors de la compilation du noyau).
Je fait confiance à SuSE/Redhat/Mandrake pour creer un utilitaire sympa pour integrer facilement les periph USB tel le scanner, Webcam, Imprimante (en partie fait), Joystick (souris c'est deja fait), ainsi que les nouveaux accessoires comme les HD, Zip, Graveur (meme si je trouve ça debile d'utiliser l'USB pour tel genre de periph).
Je me pose quand meme une question :
Linux 2.4.6 va t-il integrer l'USB 2 , Firewire et les nouvelles normes, pour ne pas etre a la traine face aux Windows XP # et Mac os # ?
(PS : j'aimerai bien jouer les Kernel Hacker et apporter ma modeste contribution pour l'integration de ces normes, mais franchement, comment voulez vous qu'un arriviste qi n'a pas suivi le debut du developpement du kernel puisse comprendre tout le code !)
[^] # Re: Le noyau aujourd'hui et demain...
Posté par ashram4 . Évalué à 1.
J'en profite pour demander si il y a un programme pour controler mes enceintes Altec Lansing sur port USB car j'ai vu qu'il existe un module dans le noyau pour controler des périphérique sonores de ce type mais il n'y a aucune autre explication.
# A propos...
Posté par rahan . Évalué à 1.
Quelqu'un a des infos ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.