> Attention, je n'ai jamais dit que c'était Mandrakelinux le problème
Mouaiff.
Perso, j'ai envi de dire que c'est MandrakeLinux le problème.
> il apparaît que Red Hat patche fortement ext3fs
En troll il apparaît que Red Hat patche fortement ext3fs. En réalité ce n'est pas le cas.
Les derniers patchs ext3fs spécifiques Red Hat étaient pour ext2online (redimensionnement à chaud) et reservation (fait par un développeur IBM je crois). Ces patchs sont apparus dans FC3 et ils sont maintenant upstream (2.6.10).
Mais on peut aussi dire que Red Hat patche ext3fs car ils sont les principaux développeurs/mainteneurs ext3.
> mais je n'ai encore qu'1 mois de backend de Fedora, donc ce n'est pas suffisant pour juger d'une meilleure stabilité.
Juste.
Mais cherche les corruptions d'ext3fs sur les mailings Red Hat. Tu verras que c'est *très* rare et que Red Hat prend ça très très au sérieux surtout que Red Hat est le principal mainteneur de ext3fs et c'est le seul fs que supporte Red Hat (les autres étant fournit pour "dépanner").
Enfin, Red Hat distribue/supporte un FS qu'ils peuvent maintenir/développer. Ils ont les compétences en interne pour le faire. Mandrake a peu de compétence à ce niveau. SuSE a les compétences pour reiserfs.
> L'ironie dans l'histoire, c'est qu'en presque 10 ans de NTFS
Le problème est peut-être là. J'ai déjà vu des plaintes sur mailing Red Hat pour ext3fs corrompu. À l'époque le diagnostique était que le driver ntfs (même en lecture seul) foutait le bordel dans la mémoire du noyau et donc polluait ext3fs.
Ce n'est pas la première fois qu'un drivers fout ce type de "bordel". Or le noyau de Mandrake est très patché en driver (beaucoup beaucoup plus que Fedora/Red Hat) pas tous très rigoureux puisqu'ils ne sont pas upstream. Ceci explique peut-être celà.
Je ne jète pas la pierre à Mandrake. Sûr que beaucoup sont contents d'avoir ces drivers à disposition.
> Tout ceci pour dire que je me demande encore pourquoi un système de fichiers aussi plantogène est encore utilisé sur un serveur
Pantogène sur Mandrake.
Des problèmes ont existé sur Fedora/Red Hat. Mais ceux dont j'ai souvenir était durant les phases beta. Pour les autres problème, c'est souvent lié à IDE qui peut changer l'ordre d'écriture si le cache est activé et c'est très embêtant en cas de coupure de courrant. Avec linux > 2.6.? c'est maintenant géré si le disque supporte "cache flushes" (un vague équivalent de tag queue de SCSI). Ce problème n'est (n'était) pas spécifique à ext3fs.
Il y a aussi les problèmes des cartes IDE qui déconnent en cas de coupure de courant et envoient n'importe quoi comme ordre aux disques lors d'une coupure de courant.
Il y a aussi évidemment les disques dures en fin de vie.
Le dernier problème connu est l'incompatibilité de resize2fs avec ext3fs qui supporte le redimensionnement à chaud. Dans ce cas il faut faire un e2fsck.
> Décidement, vivement que reiserfs4 arrive !
Mouaif.
reiser 4 ne fait pas l'unanimité chez les développeurs Linux. Il a des deadlock que Hans ne veut pas corriger car selon lui dans la pratique ça ne peut pas arriver, il introduit des incompatibilités, n'a pas d'équivalent de ordered de ext3fs (c'est certe plus lent que le classique mode "journal" mais c'est plus sûr), n'a pas de fsck fiable (c'est la doc reiserfs qui le dit) et finalement n'est pas si rapide que ça (sauf dans la pub reiserfs).
Reiser 4 ne manque pas d'idées. Mais peut-être qu'il est allé trop loin.
Pour finir sur ext3, beaucoup de distribution, et pour des raisons que j'ignore, n'active nt pas dir_index. Faire "tune2fs -O dir_index /dev/...".
[^] # Re: Il y a un truc qui m'inquiète...
Posté par fabb . En réponse au journal Parted et ext3. Évalué à 5.
Mouaiff.
Perso, j'ai envi de dire que c'est MandrakeLinux le problème.
> il apparaît que Red Hat patche fortement ext3fs
En troll il apparaît que Red Hat patche fortement ext3fs. En réalité ce n'est pas le cas.
Les derniers patchs ext3fs spécifiques Red Hat étaient pour ext2online (redimensionnement à chaud) et reservation (fait par un développeur IBM je crois). Ces patchs sont apparus dans FC3 et ils sont maintenant upstream (2.6.10).
Mais on peut aussi dire que Red Hat patche ext3fs car ils sont les principaux développeurs/mainteneurs ext3.
> mais je n'ai encore qu'1 mois de backend de Fedora, donc ce n'est pas suffisant pour juger d'une meilleure stabilité.
Juste.
Mais cherche les corruptions d'ext3fs sur les mailings Red Hat. Tu verras que c'est *très* rare et que Red Hat prend ça très très au sérieux surtout que Red Hat est le principal mainteneur de ext3fs et c'est le seul fs que supporte Red Hat (les autres étant fournit pour "dépanner").
Enfin, Red Hat distribue/supporte un FS qu'ils peuvent maintenir/développer. Ils ont les compétences en interne pour le faire. Mandrake a peu de compétence à ce niveau. SuSE a les compétences pour reiserfs.
> L'ironie dans l'histoire, c'est qu'en presque 10 ans de NTFS
Le problème est peut-être là. J'ai déjà vu des plaintes sur mailing Red Hat pour ext3fs corrompu. À l'époque le diagnostique était que le driver ntfs (même en lecture seul) foutait le bordel dans la mémoire du noyau et donc polluait ext3fs.
Ce n'est pas la première fois qu'un drivers fout ce type de "bordel". Or le noyau de Mandrake est très patché en driver (beaucoup beaucoup plus que Fedora/Red Hat) pas tous très rigoureux puisqu'ils ne sont pas upstream. Ceci explique peut-être celà.
Je ne jète pas la pierre à Mandrake. Sûr que beaucoup sont contents d'avoir ces drivers à disposition.
> Tout ceci pour dire que je me demande encore pourquoi un système de fichiers aussi plantogène est encore utilisé sur un serveur
Pantogène sur Mandrake.
Des problèmes ont existé sur Fedora/Red Hat. Mais ceux dont j'ai souvenir était durant les phases beta. Pour les autres problème, c'est souvent lié à IDE qui peut changer l'ordre d'écriture si le cache est activé et c'est très embêtant en cas de coupure de courrant. Avec linux > 2.6.? c'est maintenant géré si le disque supporte "cache flushes" (un vague équivalent de tag queue de SCSI). Ce problème n'est (n'était) pas spécifique à ext3fs.
Il y a aussi les problèmes des cartes IDE qui déconnent en cas de coupure de courant et envoient n'importe quoi comme ordre aux disques lors d'une coupure de courant.
Il y a aussi évidemment les disques dures en fin de vie.
Le dernier problème connu est l'incompatibilité de resize2fs avec ext3fs qui supporte le redimensionnement à chaud. Dans ce cas il faut faire un e2fsck.
> Décidement, vivement que reiserfs4 arrive !
Mouaif.
reiser 4 ne fait pas l'unanimité chez les développeurs Linux. Il a des deadlock que Hans ne veut pas corriger car selon lui dans la pratique ça ne peut pas arriver, il introduit des incompatibilités, n'a pas d'équivalent de ordered de ext3fs (c'est certe plus lent que le classique mode "journal" mais c'est plus sûr), n'a pas de fsck fiable (c'est la doc reiserfs qui le dit) et finalement n'est pas si rapide que ça (sauf dans la pub reiserfs).
Reiser 4 ne manque pas d'idées. Mais peut-être qu'il est allé trop loin.
Pour finir sur ext3, beaucoup de distribution, et pour des raisons que j'ignore, n'active nt pas dir_index. Faire "tune2fs -O dir_index /dev/...".