> Le ext3 a été dégagé pour d'autre raison :
> - perte de donnée
C'est marrant. Un mec fait un test avec ext3 et a des pertes de données. De nombreuse (million?) personnes utilisent ext3 et n'ont pas de pertes de données (ou c'est très rare).
> - corruption totale d'une partiton de 67Go !
cf ci-dessus. Si ext3 était naze, tu crois que Red Hat l'utiliserait ? Red Hat l'utilise pour des données critiques sur des gros serveurs et doivent tourner 24/24 7/7 365/365.
> (alors que je faisais des sync régulier pour l'éviter et aucune freeze lors de ces sync)
Si t'as un système qui freeze, alors tu as d'autres problèmes. Problème hardware ou problèmes qui écrit n'importe où en mémoire. Dans ce cas tous les FS peuvent se planter (avec perte de données et tout).
Il y a eu le cas avec ext3. Le module ntfs (même en ro) écrivant n'importe ou en mémoire et foutait la merde dans les données d'ext3. Il y a eu des cas de FS irrécupérable. NB : ntfs a été corrigé.
Il y a eu aussi ce problème avec le module NVidea.
> - pas de fsck de 3h, tu remonte et paf c'est finis
Avec ext3, ce n'est qu'une question de configuration. Fais "man tune2fs" et "man fstab".
Sans fsck complet, il est impossible pour un FS de détecter un problème hardware (sauf via le retour des fonctions read() et write()). Donc un fsck régulier, même s'il n'est pas exigé par le FS, ne peut pas faire de mal. Loins de là.
> je tourne en 2.6.20tmb
Ben si tu tournes avec des noyaux en développement, plus du "bleeding edge", il ne faut pas s'étonner qu'ext3 (ou n'importe quel fs) plante.
[^] # Re: Mes benchs à moi
Posté par IsNotGood . En réponse au journal Choix d'un système de fichiers. Évalué à 2.
> - perte de donnée
C'est marrant. Un mec fait un test avec ext3 et a des pertes de données. De nombreuse (million?) personnes utilisent ext3 et n'ont pas de pertes de données (ou c'est très rare).
> - corruption totale d'une partiton de 67Go !
cf ci-dessus. Si ext3 était naze, tu crois que Red Hat l'utiliserait ? Red Hat l'utilise pour des données critiques sur des gros serveurs et doivent tourner 24/24 7/7 365/365.
> (alors que je faisais des sync régulier pour l'éviter et aucune freeze lors de ces sync)
Si t'as un système qui freeze, alors tu as d'autres problèmes. Problème hardware ou problèmes qui écrit n'importe où en mémoire. Dans ce cas tous les FS peuvent se planter (avec perte de données et tout).
Il y a eu le cas avec ext3. Le module ntfs (même en ro) écrivant n'importe ou en mémoire et foutait la merde dans les données d'ext3. Il y a eu des cas de FS irrécupérable. NB : ntfs a été corrigé.
Il y a eu aussi ce problème avec le module NVidea.
> - pas de fsck de 3h, tu remonte et paf c'est finis
Avec ext3, ce n'est qu'une question de configuration. Fais "man tune2fs" et "man fstab".
Sans fsck complet, il est impossible pour un FS de détecter un problème hardware (sauf via le retour des fonctions read() et write()). Donc un fsck régulier, même s'il n'est pas exigé par le FS, ne peut pas faire de mal. Loins de là.
> je tourne en 2.6.20tmb
Ben si tu tournes avec des noyaux en développement, plus du "bleeding edge", il ne faut pas s'étonner qu'ext3 (ou n'importe quel fs) plante.