Globalement, si vous utilisez 'journal' au lieu de 'ordered' vous risquez de perdre les 30 dernières secondes de transactions du fait d'un problème de synchronisation. Donc, la solution court terme est de faire un 'sync' avant de demonter les partitions ...
Vous trouverez donc dans le lien les infos concernant le bug ainsi que les commentaires assez acides sur le probleme.
Aller plus loin
- News KernelTrap (7 clics)
# L'autre solution
Posté par wismerhill . Évalué à 5.
[^] # Re: L'autre solution
Posté par FRLinux (site web personnel) . Évalué à 9.
Steph
[^] # Re: L'autre solution
Posté par Moby-Dik . Évalué à 1.
[^] # La vraie solution
Posté par kalahann . Évalué à 4.
[^] # Re: La vraie solution
Posté par fantomaxe . Évalué à 4.
mon /var/log/messages me dit:
Dec 2 16:26:21 debian kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,3), internal journal
Dec 2 16:26:21 debian kernel: EXT3-fs: mounted filesystem with ordered data mode.
Donc visiblement je ne risque rien, comme la majorité des utilisateurs d'ext3, vu que ordered est utilisé par défaut...
Beaucoup de bruit... pour les sites de news linux ! Pas beaucoup de conséquences pour l'utilisateur final: pour l'instant le noyau 2.4.20 n'est pas encore intégré dans une quelconque distribution Linux. Pour les pressés comme moi: oui, on prend toujours un risque en installant un noyau tout chaud !
Cependant - comme il a été dit sur Kerneltrap - les développeurs sont-ils raisonnables en ajoutant de nouvelles améliorations/fonctionnalités dans un kernel stable ?
[^] # Re: La vraie solution
Posté par FRLinux (site web personnel) . Évalué à 3.
" Pas de panique, il ne concerne que ceux qui utilisent le flag 'data=journal' qui n'est pas active par defaut (le defaut etant 'data=ordered'"
Steph
[^] # Re: La vraie solution
Posté par Anonyme . Évalué à 1.
Dec 1 12:06:47 dionysos kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,6), internal journal
Dec 1 12:06:47 dionysos kernel: EXT3-fs: mounted filesystem with ordered data mode.
Dec 1 12:06:47 dionysos kernel: kjournald starting. Commit interval 5 seconds
Dec 1 12:06:47 dionysos kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,7), internal journal
Dec 1 12:06:47 dionysos kernel: EXT3-fs: mounted filesystem with ordered data mode.
et idem... il me semblait que j'ajout de fonctionnalité était le but de la version non-stable...
[^] # Re: L'autre solution
Posté par LiNX_ . Évalué à 1.
kezako 'sync' ?
[^] # Re: L'autre solution
Posté par matiasf . Évalué à 1.
[^] # Re: L'autre solution
Posté par Olivier Jeannet . Évalué à 3.
C'est une commande de base du système, qui permet de synchroniser le contenu du disque avec celui du cache (en pratique, écrire sur le disque les buffers "sales" en mémoire, s'il y en a).
Normalement sur un système Unix, au bout de 30 secondes d'inactivité (si aucun programme n'écrit sur disque), la synchronisation est effective (il y a un "timeout" pour forcer l'écriture des buffers sales au bout d'un certain temps). Sur certains systèmes ça peut être moins, genre 5 secondes.
[^] # Re: L'autre solution
Posté par matiasf . Évalué à 0.
J'utiliserai jamais sync. Il est hors de question que l'OS me foute des trucs "sales" de la mémoire sur mon disque.
J'ai dit !
[^] # Re: L'autre solution
Posté par woof . Évalué à 0.
Je te conseille dd if=/dev/zero of=/dev/hda
(ca lave plus blanc que blanc)
# Re: Bug ext3 dans le kernel 2.4.20
Posté par Matho (site web personnel) . Évalué à 10.
Mais bon cela prouve toujours qu'en environnement de prod, même upgrader un kernel ne se fait pas/plus "comme ça".
Il faut maquetter, maquetter encore, attendre du feedback et lire les newsgroups, avant de faire un backup complet avant de se lancer.
C'est con. Mais c'est safe.
ps : Allez bon courage Marcelo.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par pfrenard . Évalué à 0.
rien de tel que le bon veil adage "quand ca marche, touche a rien"
malgres tout, upgrader un kernel linux est tres safe, au pire un boot sur lancien kernel et ca repart
contrairement aux OS commerciaux ou j'ai jamais vu ca.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Yngwiemanux . Évalué à 0.
Cordialement.
# Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à -4.
Les gens qui utilisent un 2.4.20 avec ext3 en mode journal sont pas nombreux.
Ce chois de mettre ce bug en première page est d'autant plus ridicule que l'adoption par radio france de Windows Media passe dans la page autre. Et n'ai déjà plus visible...
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par nicolas garnier . Évalué à 5.
J'utilise plus le noyau 2.4 que j'écoute Radio France (en WMA, RA, QT ou en banane volante d'ailleurs).
Le fait de pouvoir avoir un retour d'utilisateur sur leur montage ext3 et sur les bugs des noyaus stables est toujours bon à prendre pour le buolot et pour soi-même.
Ca aide à prendre de bonnes décisions quand on vient te demander ton avis.
Enfin c'est mon avis perso à moi que j'ai aussi.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par esprit . Évalué à 10.
Et puis ca oblige a faire preuve d'humilité, histoire de montrer exemple aux utilisateurs d'autres OS. Bah oui y a des problemes des fois dans linux (le noyau), on cherche pas a le cacher, au contraire meme, on est bien content de les trouver pour les corriger :-)
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 1.
Le chois de Radio France rend impossible l'utilisation de Linux pour lire du audio/video et il n'est pas très freesoftware friendly.
> Le fait de pouvoir avoir un retour d'utilisateur sur leur montage ext3 et sur les bugs des noyaus stables est toujours bon
Vrai. Mais linuxfr n'est pas dédié noyau Linux.
> Ca aide à prendre de bonnes décisions quand on vient te demander ton avis.
Mouais. On te demande souvent : "tu préfères quoi ? le 2.4.18 ou le 2.4.20 ?"
Pour une machine de prod, je prend le noyau du distributeur. Et pour un usage perso aussi... (depuis le 2.4 car avec le 2.2 il fallait une tonne de patch pour la carte TV, i2c, le support de hpt370, etc...).
Que ceux qui utilise un noyaux 2.4.20 avec ext3 en mode journal lève le doigt.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par FRLinux (site web personnel) . Évalué à 3.
Euh non. Enfin, oui pour les serveurs mais pas pour le perso. Tu veux un exemple pratique ? La reinstall de ma partoche RAID hier avec une MDK 9.0 flambant neuve, je fais de la copie a la volee de mes CDs de backups vers la partoche RAID et au lieu de recopier les 650MO des CDs, il me recopiait aleatoirement 100/150MO des CDs et ensuite se vautrait en disant : /mnt/cdrom/blah not found. Alors que tout etait la.
Eh bien, c'etait un noyau du distributeur, j'ai ensuite installe un 2.4.19 vanilla et devine quoi ? Plus de probleme, j'ai perdu le support supermount mais je m'en sers pas ;) Perso, ca fait un moment que je n'aime plus les noyaux du distributeur (et j'en ai aussi pour RedHat vu que j'administrais des serveurs RH avant). Depuis que j'ai tout sous Debian, je suis un admin heu-reux.
Steph
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 2.
> je n'aime plus les noyaux du distributeur
J'utilise pratiquement que RedHat et sans problème. Sauf avec la RH 8.0 où j'ai deux trucs qui m'énerve :
1 - le processus X a çà priorité fixé à -10 par le noyau. C'est le noyau et non les scripts de lancement de X qui fixe cette priorité et je trouve çà stupide. RedHat semble revenu en arrière puisqu'il n'y a plus cette "fonctionnalité" dans le noyau rawhide.
2 - J'ai des problèmes de clavier sous X. La répétition automatique est parfois abusive ou elle se déclenche sans délais. C'est très gonflant par moment.
Pour moi, les noyaux 2.4.19 et 2.4.20-rc? (j'ai pas testé le 2.4.20) sont moins bon que le 2.4.18 (heureusement la RH8.0 utilise un 2.4.18). En effet dans le 2.4.x (x >= 19) il y a un backport partiel de l'IDE du 2.5 (suite aux nombreux problèmes IDE sous 2.5, Alan Cox est temporairement responsable de l'IDE. Pour bosser, il ne voulais pas être pollué par les autres problèmes du 2.5).
Avec les nouveaux 2.4 je ne peux activer le dma pour le dvd et cdrom de la carte ide hpt370. De plus, s'il y a une erreur avec un cdrom, je ne peut plus le démonter. C'est un problème connu, AC indique qu'il n'est pas prévu de correction à court terme (tant que le gros du travail sur IDE n'est pas terminé).
Je comprend les motivations d'AC de bossé sur le nouveau IDE sous 2.4 mais c'est quand même gonflant.
Enfin, depuis le 2.4.18 (officiel ou non) mon système freeze aléatoirement (au bout de 20 min ou 10 heures) si j'active le dma de la carte IDE VIA VT82C586B (KT266) et utilise bttv en même temps. Bizarrement je n'ai pas de problème avec le 2.4.17 ou le 2.4.9RH. J'ai également ce problème avec un 2.5. Modules bttv contruits hors de l'arborescence de linux car bttv livré avec 2.5 ne se compile pas actuellement. Lorsque bttv marchera avec la version officiel, je posterai un rapport de bug.
Bref, depuis que je suis passé sous RH8.0 j'ai plein d'emmerde à cause du noyau (officiel ou non). Et j'ai testé plein de nouvelle version sans réelle succès. Je suis actuellement avec le noyau officiel de RedHat mais avec de petit problème de clavier sous X et dma désactivé pour une carte IDE.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par FRLinux (site web personnel) . Évalué à 2.
Steph
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 1.
Oops, j'ai pas remarqué que je causais à Frlinux.
> ces pauvres utilisateurs qui decident de passer a Linux en installant la derniere RedHat a la mode
Je conserve longtemps mes distribes et ne saute pas sur les nouvelles versions et j'évite les x.0 de RedHat qui ne sont pas toujours très fiable (normal pour une .0). J'ai utilisé une RH 4.2, 5.2, 6.2, 7.2 et j'ai installé il y a un mois une RH8.0 car ma RH7.2 (que j'utilisais depuis un an) c'est planté avec corruption massive de ma partition racine (/etc perdu, /var/lib à moitier détruit... une horreur... alors que j'utilise remount-ro sur erreur) pour des raisons inconnus.
Pour revenir à la RH8.0 j'ai aussi eux des problèmes de reconnaissant de ma partition raid 0 à l'install (parfois reconnue parfois non). La RH8.0 est globalement une bonne distribe mais pas parfaite :
- rpm parfois en deadlock (faire un : cd /var/lib/rpm ; db_recorver)
- problème clavier sous X
- utilisation utf8 partout alors que toutes les applis ne le supportent pas
- gestionnaire de fenêtre metacity de qualité mais simpliste (j'ai remis icewm).
Par contre, son noyau est fiable (pour ma bécane). C'est pas nouveau, les RH x.0 sont connues pour leur manque de "finission". Mais c'est normal puisqu'elle introduisse de nouvelles fonctionnalités (la RH8.0 c'est Gnome 2.0, gcc 3.2, utilisation systématique d'utf8, apache 2 en standard, bluecurve etc...). Les versions suivante seront meilleurs (comme les 7.x ont corrigées les problèmes de la 7.0). D'ailleur les versions plus ciblées serveur de RedHat ne sont jamais basées sur une x.0. Donc il faut retenir que les x.0 sont pour les "aventuriers" (le .0 doit même la puce à l'oreille).
Si je ne juge RedHat que sur la RH8.0 je peux être déçu (comme toi). Mais les autres RedHat que j'ai utilisé étaient très bonnes, bien finies et sans fioritures qui plantent. Enfin avec RedHat il ne faut pas oublier leur énorme contribution au free software (c'est les plus gros contributeur pour Gnome (quoique Sun arrive en force), gcc, Linux, rpm). C'est un point qui devrait être pris en compte.
Bref tu ne devrais pas avoir un avis définitif sur RedHat seulement car la dernière version n'est pas au top.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par FRLinux (site web personnel) . Évalué à 1.
Je n'ai pas un avis definitif. J'ai decouvert RedHat avec la 4.2 a l'epoque. Je ne connaissais que Slackware 2.0 a l'epoque. J'ai ensuite evolue avec RedHat 5.0, 6.2 puis toutes les 7.x, j'ai eu sur mon systeme perso autant des RH que des MDK. Mais ma tendance depuis 8 mois se tient vers MDK. J'aimais bien RedHat en tant qu'utilisateur, je prefere actuellement Mandrake qui je trouve apporte un petit plus en station de bureau (c'est prouvé).
Je ne denigre pas le travail de contributeur libre de RedHat, je ne l'ai meme pas mentionné. Toutes les distributions qui se veulent de qualité fournissent un bon niveau de patches et autres a Linux, y'a pas vraiment a discuter la dessus.
Je disais juste que sur la RedHat 8.0 uniquement, j'ai jamais eu autant de mails de personnes n'arrivant pas a l'installer.
Enfin, j'ai tendance a penser comme toi, ne pas migrer a une .0 mais voila, j'avais besoin de repartionner violemment mes HDD, j'en ai donc profite pour mettre une version plus recente de Mandrake, d'ailleurs considerant ce que je lui ai mis dans la tete en recompilation maison, c plus vraiment une .0 mais une .01-steph ;)
Steph
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Baptiste SIMON (site web personnel) . Évalué à 1.
Depuis la mdk-9.0 je n'ai jamais eu autant de pote motivés par le passage sous GNU/Linux... je n'ai jamais eu non plus autant d'échos de problèmes d'install sur celle-ci.
Cela dit, je ne retire pas le fait que je pense qu'une bonne partie d'entre eux ne sont pas foutus de savoir ce qu'est une vérification de md5 dans le concrêt !
En plus, je suis un ex-mandrakiste...
Donc tout cela est contradictoire... je suis fatigué d'attendre mon identifiants Nerim (merci FT)... donc je --> [] ! :c)
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
pareil, j'en ai installe une pour un copain et cette nouille etait pas capable de demonter le lecteur CD lors du changement de disque, meme pb chez un autre, et pas de pb sur le 3me. Il ma fallut du tps (et un bidouillage sur une mdk 8.2) pour comprendre qu'elle se perd les pedales lors qu'on a plus d'un lecteur/graveur CD ..... s'pas sérieux ca je fait comment moi avec mon lecteur DVD, mon graveur et mon lecteur CD :)
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Jak . Évalué à 1.
J'avais essayé de compiler le BTTV avec un 2.5.48, et je ne me souviens plus où j'en étais resté. J'avais réussi à trifouiller pour faciliter la compil' (dont une groose merdouille en récupérant un bout de code dans fs/select.c qu'il ne trouvait pas (?), mais bon ...)
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 1.
Les derniers driver bttv sont dispos ici :
http://bytesex.org/bttv/(...)
> Comme le patch disponible n'est que pour le dernier 2.4.20, à première vue, ben, tant pis
Les modules bttvs peuvent être construit hors de l'arborescence de Linux (sans patché les sources Linux). J'ai déjà installé la version 0.7.100 sur 2.4.17.
> J'avais essayé de compiler le BTTV avec un 2.5.48
bttv livré avec Linux 2.5 ne compile pas actuellement.
Par contre bttv de http://bytesex.org/bttv/(...) marche sous linux 2.5.
Peux tu être plus précis sur tes problèmes de freeze. J'aimerai savoir s'ils sont similaires aux miens.
Pour info :
[f.matias@one f.matias]$ /sbin/lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT333 AGP]
00:05.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 03)
00:06.0 Multimedia video controller: Brooktree Corporation Bt848 Video Capture (rev 12)
00:07.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
00:08.0 ATM network controller: SGS Thomson Microelectronics: Unknown device 0500 (rev 10)
00:09.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus DVD Decoder (rev 02)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE (rev 06)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP (rev 7a)
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Jak . Évalué à 1.
Ben, sinon, pour les gels système, ça ne m'est pas arrivé très souvent (je n'utilise le 2.4.20-rc3 que depuis environ 2 semaines). J'ai remarqué ça une ou 2 fois en ayant lancé de nombreuses fois MPlayer pour regarder l'entrée TV, mais il y a des sessions où j'ai fréquemment regardé la télé sans que ça ne pose problème. Pas évident à reproduire.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 1.
C'est très simple. Tu récupère l'archive tar.gz. Tu lis le README. Puis il y a un "make" suivi d'un "make install" (un truc comme çà mais guère plus compliqué).
> mais il y a des sessions où j'ai fréquemment regardé la télé sans que ça ne pose problème.
J'ai le problème lorsque l'utilise bttv (la même carte que toi même plus récente "rev 12" via xawtv) ET les disques sur le controleur VT82C586B (très proche du tien) avec dma activé. Il faut noté que je n'ai pas ce type de problème avec le controleur hpt370.
> Pas évident à reproduire.
Facile pour moi.
* utilsé xawtv (fenêtre la plus grande possible)
* activé le dma pour les disques durs.
C'est activité par défaut chez moi. Si ce n'est pas le cas faire :
# hdparm -d 1 /dev/hda
# hdparm /dev/hda
[...]
using_dma = 1 (on)
[...]
* stresser le disque dur tout en visualisant xawtv
Par exemple
# tar cf /dev/null /
Si cette procedure fait planté ta bécane, peux tu faire un essai sans dma (hdparm -d 0 /dev/hda) ?
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Jak . Évalué à 1.
J'ai également toujours le DMA activé. Bon, j'essaie, pour voir.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Jak . Évalué à 1.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 1.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Jak . Évalué à 1.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 1.
J'ai mis à jour mon bios et je n'est plus ce problème. Bizarre, bizarre car je n'ai pas de problème avec Linux 2.4.17.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Sebastien (site web personnel) . Évalué à 1.
> > Pour une machine de prod, je prend le noyau du distributeur. Et
> > pour un usage perso aussi...
> Euh non. Enfin, oui pour les serveurs mais pas pour le perso.
Ahem, en cas général, personnellement, sur des serveurs, je mettrai un noyau compilé moi même plutôt que celui du distributeur. Et accessoirement, je supprime tous les modules ainsi que le support pour les modules. Comme ça, le noyau est "complet" dès le démarrage et il va pas changer d'état en cours de route pour un oui ou un non.
Le seul cas, vraiment, ou je laisserai celui du distributeur, c'est dans le cas où distributeur et fabricant de la machine ne feraient qu'un.
Pour le perso, après, de toutes les manières le support du distributeur est bien suffisant et à part pour bidouiller ou jouer, changer de noyau ne changera pas grand chose ...
seb.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Anonyme . Évalué à 1.
Dans le cas d'un serveur de production, il reste sans doute plus certains de faire confiance aux noyaux des distributeurs (meme recompilé soit meme)
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 2.
Pour changé d'état, le module doit être déchargé puis reloadé. Pour décharger un module il faut qu'il ne soit plus utilisé. Avec Linux 2.4, les modules ne sont pas déchargé automatiquement (contrairement à Linux 2.0 et 2.2 où kerneld le fesait automatiquement). Par contre, il y a parfois un cron avec "rmmod -a".
Bref, çà ne change pas d'état pour un oui ou un non. Mais uniquement si le modules n'est pas utilisé (ce qui ne pose plus de problème) et sur demande explicite de root. Par contre les modules peuvent être chargé implicitement. Mais si tu as compilé que les modules nécessaires, ce n'est pas un problème. De plus tu peux compilé ton noyau sans CONFIG_KMOD et dans ce cas il n'y a plus de load implicite des modules.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
Moi, j'avais le même problème et j'ai enlevé le supermount, tout fonctionne sans problème maintenant ! (mount et umount à la main)
Sur mon lecteur ZIP, quand j'effaçais des fichiers, il n'enlevait que la référence et laissait l'espace marqué occupé... (sauf si je la laissais réellement longtemps après la manip dans le lecteur).
Et sur le lecteur CD, en principe, le premier CD passe, mais pas les suivants (on dirait qu'il ne remet pas à jour l'arborescence en mémoire en fait).
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à -1.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Moby-Dik . Évalué à 1.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 1.
Je te donne un [+], c'est cadeau.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par nicolas garnier . Évalué à 0.
> Vrai. Mais linuxfr n'est pas dédié noyau Linux.
Non, mais la news en l'occurence, oui.
>> Ca aide à prendre de bonnes décisions quand on vient te demander ton avis.
> Mouais. On te demande souvent : "tu préfères quoi ? le 2.4.18 ou le 2.4.20 ?"
Bah la dernière fois c'était la semaine dernière : "Dis, faut prendre quoi comme version de noyau pour Linux ?"
> Pour une machine de prod, je prend le noyau du distributeur.
Perso j'évite, parce que les patchs à deux balles de M. RedHat non documentés et non testés, c'est cool pour les features mais pas pour la stabilité. Le revers de la médaille c'est que tu te mets dans la merde pour le support RedHat ou Oracle.
"Ah bah non on ne supporte pas, vous n'avez pas le noyau "offciel" !"
"Bah si, mais c'est pas le votre"
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 6.
C'est des patchs que tu retrouves plus tard dans la branche officiel. Le plus gros patch étant celui d'Alan Cox (il y a souvent un ac? dans les noyaux officiel RH).
Puis je trouve minable de critiquer RedHat par rapport au noyau alors que c'est le distributeur qui contribue le plus au noyau (6 des développeurs du top 10 de Linux bosse cher RedHat). Je veux dire qu'il peuvent faire des conneries (çà arrive à tout le monde et j'ai même posté un truc ici critiquant la dernière RH8.0) mais parler de "patchs à deux balles" c'est minable. Il est claire que si Debian ne patche pas le noyau Linux et ne participe pas au développement de Linux tu ne risques pas de les critiquer.
> c'est cool pour les features mais pas pour la stabilité.
RedHat met rarement les dernières version de noyau dans leur distribe. La RH8.0 sortie en même temps que MdK 9.0 est en 2.4.18 et non 2.4.19. Il sont longtemps resté en 2.4.9 alors que les autres à la même époque proposait le 2.4.14. RedHat est parfois "lent" pour l'adoption de nouvelle solution. Par exemple reiserFS a été intégré bien après les autres distribes (l'histoire montre que c'était à juste titre). La RH8.0 s'est vu retiré le support d'ACL (il était annoncé en beta) car insuffisament fiable selon RedHat alors qu'il est présent sur Mandrake et Suse, etc...
> Le revers de la médaille c'est que tu te mets dans la merde pour le support RedHat ou Oracle.
Pour Oracle je ne sais pas. Pour RedHat je ne crois pas. J'ai déjà vu un bug accèpté sur http://bugzilla.redhat.com/(...) pour un programme car il ne marchais pas avec la dernière version officiel de Linux alors qu'il marchait avec la version RedHat.
> "Ah bah non on ne supporte pas, vous n'avez pas le noyau "offciel" !"
C'est un faux problème. Tu peux facilement avoir deux noyaux sur ta bécane, donc conserver la version RedHat. Si t'as des problèmes avec un programme avec la version Linux officiel, tu reviens sur la version RedHat pour voir si le bug existe toujours. Si c'est le cas, tu poste un rapport de bug sur http://bugzilla.redhat.com/.(...) Si c'est l'inverse, tu postes sur lkml. Tu ne peux pas demander à RedHat de maintenir leur version et la version officiel Linux !
# Re: Bug ext3 dans le kernel 2.4.20
Posté par Aza . Évalué à 1.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 5.
Si le premier sync ne marche pas je vois pas pourquoi le second va marcher.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par daggett . Évalué à 3.
parmi la thread ( http://mail-index.netbsd.org/tech-kern/1999/01/(...) )
on trouve http://mail-index.netbsd.org/tech-kern/1999/01/15/0004.html(...)
The original reason the old Unix hacks always recommended typing
"sync<CR>" three times before powering down the system was that doing so
on a sticky old teletype machine usually took long enough that the first
command had actually taken effect and by the time you could reach for
the power switch on the cabinet beside you the disks would have really
completed their writes.
Une justification éventuelle pour faire 2 sync au lieu d'un (je ne sais pas si c'est toujours le cas sous Linux) est que sync rend la main alors que les données ne sont pas forcément écrites :
sync() returns once I/O for all delayed writes has
been scheduled, but not completed. That is, it converts
delayed writes into asynchronous writes, which usually
complete after it exits.
Enfin, mieux vaut faire trop de syncs que pas assez :)
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Thomas Cataldo (site web personnel) . Évalué à 2.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par arf . Évalué à 2.
La commande sync rendait la main tout
de suite et donc on ne savait pas si le sync
s etait bien passé. Par contre le second appel de
sync se fait que si le premier est terminé.
D ou le sync ; sync.
Cela etait vrai sur les vieux systemes Unix
maintenant je ne sais pas ce que ca vaut...
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par GCN (site web personnel) . Évalué à 2.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Pooly (site web personnel) . Évalué à 1.
De toute façon, tout le monde devrai avoir un sync dans ses script de halt et reboot :)
# Linux 2.5 => C'est le moment de tester !
Posté par matiasf . Évalué à 7.
N'hésiter pas et tester Linux 2.5 avec votre hardware et poster des rapports bugs (lire /usr/src/linux/README et /usr/src/linux/REPORTING-BUGS) s'il y a des problèmes. Ce petit geste améliorera la qualité de Linux 2.6 et vous donnera plus de chance d'avoir un noyau qui marche nickel sur votre hardware et votre configuration.
L'autre aspect positif de cette base de bug est la traçabilité, une bonne vue de l'état actuelle du noyau et la possibilité de recherche. C'est beaucoup plus pratique que lkml. Des patchs sont parfois dispos dans bugzilla.kernel.org alors qu'il ne sont pas encore intégrés à la version officiel. Afin, lorsque vous faite un rapport de bug, la personne responsable de la partie du noyau incriminée est automatiquement contactée.
Cette base de bug est généreusement offerte par ibm et osdn. C'est principalement du personne ibm qui maintient cette base.
Le noyau 2.5 doit fonctionner sans problème ( :-o ) avec toute distribution moderne. Néanmoins il faut utiliser un nouveau modutils (pas encore totalement finalisé). Récupérez le ici :
http://www.kernel.org/pub/linux/kernel/people/rusty/modules/(...)
Ce nouveau modutils marche parfaitement avec Linux 2.4 (il utilise l'ancien modutils sous 2.4). Il n'y a donc aucun problème pour rebooter sous 2.4.
Le "make menuconfig" pose problème avec une RH 8.0 sous une console virtuelle Linux. En effet la RH 8.0 utilise unicode par défaut sur les consoles virtuel Linux et "make menuconfig" ne supporte pas unicode actuellement. Dans ce cas, faire :
$ unicode_stop
$ export LANG=C # pas obligatoire
# Re: Bug ext3 dans le kernel 2.4.20
Posté par gerard delafond . Évalué à -1.
Résultat : un boulot de 2 jours perdu.
Conclusion quelle que soit votre version de kernel, utilisez Reiserfs.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par matiasf . Évalué à 0.
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Moby-Dik . Évalué à 0.
Moi j'ai toujours eu des galères monstres avec emacs :-)
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par wismerhill . Évalué à 2.
Y a aussi fat, celui-là vu qu'il n'a à peu près aucune fonctionnalité c'est difficile qu'il fonctionne pas correctement (c'est pas pour rien que n'importe quel os le supporte).
[^] # Re: Bug ext3 dans le kernel 2.4.20
Posté par Anonyme . Évalué à 1.
# Re: Bug ext3 dans le kernel 2.4.20
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
Après consultationnage de la manpage de halt, il semblerait que ce soit systématiquement fait. Ce bug a-t'il donc un impact réel ?
# Release candidates
Posté par Alain Tésio . Évalué à 1.
C'est sûr ca se voit moins qu'une nouvelle fonctionnalité dans Mozilla, mais vous pourriez faire un petit effort !
Il y a des patches sur tous les miroirs dans les sous-répertoire testing.
[^] # Re: Release candidates
Posté par daniel . Évalué à 1.
On peut aimer tester des softs, envoyer des rapports de bugs pour aider au développement, mais on n'a pas forcément une machine à casser.
[^] # Re: Release candidates
Posté par matiasf . Évalué à 1.
très, très, très, très, très rarement...
> mais on n'a pas forcément une machine à casser.
Ben tu peux avoir un disque dur pour les tests.
Moins j'ai un disque dur de "production" et un de backup. Pour les tests risqués je les fais sur le disque de backup. Une foi le test terminé, je refais un backup (avec rsync).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.