Maintenant qu'un noyau stable digne de ce nom intègre ext3, je vous soumets un document que j'ai rédigé sur l'installation et l'utilisation d'ext3, ainsi qu'une petite série de benchs ext2/ext3/reiserfs made in maison.
Bien sûr. C'est marqué dans les conditions de test
de chaque bench, un peu noyé peut-être. Mais bon, c'est
la moindre des choses de respecter ces conditions:)
Pourquoi ne pas avoir incoproré également des tests avec XFS et JFS qui sont disponibles depuis longtemps en patch pour le noyau 2.4 et dont la stabilité et les fonctionnalités (au moins pour XFS) sont bien supérieurs à ext3 et reiserfs ?
Personnellement je teste JFS sur ma machine, la 1.0.10 est d'ailleurs sortie hier, et je n'ai pas eu de problèmes. Cela fait également plusieurs mois que je fais des install chez nos clients en RedHat-XFS et je n'ai jamais eu aucun problèmes.
J'ai indiqué ces liens dans mon doc sur ext3. Note que
dellomodarm parle et fait des tests avec ext3 sous linux
2.2. Un regard un peu attentif sur le tableau des résultat
aurait decelé quelque chose de fantaisiste :), aussi
je n'ai pas (n'ai-je pas) une confiance énorme.
En fait, ses bench sont tous fait sur 2.2 sauf pour xfs, qui a été fait en 2.4.2 ... Il est vrai que ces tests datent un peu, et que tout a beaucoup évolué ces derniers temps. A prendre donc avec des pincettes.
Par contre l'article technique sur les systèmes journalisés est réellement très intéressant.
Le probleme c'est que ces deux systemes sonts pas toujour a jour par rapport au versions du noyau ce qui est, dans les periodes troubles que nous avons traverses, un detail important
Sinon ext3 meme si c'est un systeme de fichier journalise un peu simplifie, son point fort c'est qu'il permet de garder la compatibilitée avec ext2 et ca c'est extremement important surtout en production, on peut meme faire la mise a jour sans avoir a passer par les fastidieuses phases de reformatage & co
> son point fort c'est qu'il permet de garder la compatibilitée avec ext2.
Il supporte aussi la journalisation de donné et çà c'est bon pour la conhérence des données.
> Sinon ext3 meme si c'est un systeme de fichier journalise un peu simplifie.
Je me marre. Avant tout le monde ne jurait que par reiserfs car il y avait plein d'article sur reiserfs. Le développeur principale, Reiser, se répendait dans des :
- reiserfs c'est le meilleur.
- pourquoi utiliser un autre système de fichier journalisé.
- etc...
Pour ext3, les gus bossent dans l'ombre sans faire de communiqués. Au bout d'un moment, les gens pensent d'ext3 est un "systeme de fichier journalise un peu simplifie". N'empéche que lorsqu'il est intégré au noyau Linux, il n'y a pas de problèmes (rien dans le changelog 2.4.16 et 2.4.17-pre1.
En "truc nouveau" ext3 c'est :
- 3 mode de fonctionnement du journal.
- la journalisation des données.
- supporte tout : NFS, quota, lvm, dès sa sortie et pas 8 mois après...
- un journal qui peut-être sur un autre périphérique.
- Du code propre et une implémentation générique qui devrai permettre au développeur ext3 de journir la journalisation à n'importe quel système de fichier (imagine vfat avec journalisation...).
Alors c'est peu-être simple mais c'est efficace et çà MARCHE.
Le fait qu'il soit simplifié ne lui enleve pas ses qualité, mais c'est bien une simplification.
si tu suis les liens proposé tu peux voir que ext3 ne gere pas l'allocation dynamique d'inode, ni les extents.
Mais on peut tres bien vivre sans tout ça :)
> Et est ce que la taille max d'un fichier est toujours 2 Gb ?
Non. Suivant la taille des blocks, la limite est la suivante:
Filesystem block size: 1kB 2kB 4kB 8kB
File size limit: 16GB 256GB 2048GB 2048GB
Cf. linux/Documentation/filesystems/ext2.txt. C'est la limite
côté noyau. Pour le côté userland, il faut avoir
une glibc-2.2 ou supérieure, et éventuellement recompiler
les programmes (ls, mv, etc). Mais c'est un peu off-topic :)
Ça, je me demande comment ça peut être implémenté sans problèmes de performances. Il ne faut pas oublier que le disque dur, il est lent, et les performances globales du système sont donc fortement dépendantes du fs dans pas mal de cas.
- Du code propre et une implémentation générique qui devrai permettre au développeur ext3 de journir la journalisation à n'importe quel système de fichier (imagine vfat avec journalisation...).
Ça existe, c'est NTFS :)
Pour revenir au sujet, ext3 a mis beaucoup plus de temps à être développé que reiserfs, c'est donc normal qu'il soit plus mature à sa sortie (surtout qu'ils ont pu faire attention aux problèmes rencontrés par les autres fs). Et je ne vois pas en quoi les grandes qualités de ext3, qui doivent être soulignées, devraient rabaisser celles de reiserfs.
> Ça, je me demande comment ça peut être implémenté sans problèmes de performances.
C'est pas évidant. Les gestionnaires de base de données type Oracle, PostgreSQL, etc... qui utilise les transactions, implémentent un équivalent de journalisation de données sans impacte significatif sur les performances (parfois c'est même plus rapide !).
Mais les benchmarks montre d'ext3 en mode order reste très performants. Perso, le gain en sécurité compense largement la petite perte de performance (mais les goûts et les couleurs...).
> Et je ne vois pas en quoi les grandes qualités de ext3, qui doivent être soulignées, devraient rabaisser celles de reiserfs.
C'est claire.
Et je suis désolé si les utilisateurs ou développeurs de ReiserFS l'ont mal pris.
J'ai lus plusieurs trucs sur ReiserFS et il contient des inovations technologiques remarquables (principalement sur la gestion des petits fichiers).
Le post que j'ai mis, était un post énervé. Enervé de lire qu'ext3 était un gestionnaire de fichier "simplifié".
Je pense qu'il ne doit pas être "simple" de faire un système de fichier journalisé équivalent à ext3 (méta-donnée, donnée, compatibilité ext2/ext3 ascendante et descendante, cohérent donc rapidement au point, etc...) et le tout parfaitement intégré au noyau Linux (NFS, Quota, ACL (pas encore en standars :o) ))..
Enfin, j'apprécie le free software et vois toujours d'un bon oeil la cocurrence (ReiserFS/ext3/XFS/.., Gnome/KDE...).
Go ReiserFS.
Go ext3.
XFS suit de très près les releases kernel, seul les 2.4.15 et 2.4.16 manquent à cause des bugs récents. Pour JFS, les versions ne suivent pas les releases kernel, mais la dernières versions s'appliquent toujours sur les noyaux qui sortent.
De toutes façon, un petit coup de vi pour placer un .rej et ca roule.
Je n'ai pas parlé de ces deux systèmes de fichiers car on
trouve des tests assez exhaustifs sur le site de namesys http://www.namesys.com/.(...) J'ai touché un petit mot sur
jfs (1.0.9) dans la partie dbench. dbench (ou jfs) s'est même
vautré pendant le test sur jfs.
...sachant que n'ai qu'une vague idée de la problématique de la journalisation d'un système de fichiers:
1. qu'est-ce qu'il ressortirait d'une comparaison à la louche entre reiserFS,ext3 et NTFS ?
2. j'ai testé récemment l'install d'une mdk8.1 avec le noyo d'origine (euh, je suis pas sur la bécane, mais à vue de nez un 2.4.3 ??), et pour la première fois en passant à reiserFS pour *toutes* mes partitions. J'ai eu de gros pb de temps de latence (peux pas en dire plus, j'avais vraiment pas le temps de chercher d'où ca venait). J'imagine naïvement qu'au premier reboot, il y a eu création du journal du filesystem de chaque partition (?) donc ca aurait pu être une explication, mais le problème a persisté bien après. J'ai refait l'install en choisissant cette fois ext3, et je n'ai pas eu ce problème. Y'en a qui peuvent trouver le diagnostic, après cette description à 2 balles ???!? (non, c'est pas un problème de swap, ca j'ai vérifié)
Il me semble reiserfs n'offre pas la possibilité de journaliser les données (à confirmer) contrairement à ext3.
Cette fonctionnalité réduit par deux les performances en écriture mais est néanmoins très intéressante pour les données sensibles. Car contrairement à ce que croient la plupart des gens, ce n'est pas parce que l'on a un système de fichiers journalisé que les dernières écritures seront saines après un crash de la machine. Le système de fichiers journalisé assure seulement un boot rapide en se passant du fsck.
Le mode par défaut (data=ordered) apporte la fiabilité des données, mais avec un coût en performances beaucoup plus faible que le mode de journalisation des données (data=journal)
Le système de fichiers journalisé assure seulement un boot rapide en se passant du fsck
Il assure en fait la cohérence de la structure du système de fichier, c'est à dire qu'on ne risque pas de se retrouver avec des répertoires incomplets ou des inodes qui pointent n'importe où, des bouts de fichiers pas référencés, etc...
Par contre on peut très bien perdre les dernières données écrites dans un fichier.
Je recommande la lecture de l'interview de Theo de Raadt (OpenBSD), passée ici il y a quelques jours, et il donne en référence un document intéressant à lire :
"Journaling versus soft updates: asynchronous meta-data protection in file systems" http://www.usenix.org/publications/library/proceedings/usenix2000/g(...)
Il a donné cette référence en parlant de la définition du dernier état "bon" ou "stable" d'un système de fichier, en fait on peut en concevoir plusieurs.
Dans tous les benchs, ReiserFS et ext3 ont chacun des points forts mais je vois une raison essentielle qui fait que sur ma machine perso et aussi sur un serveur, je choisirai ext3 : les backups sur bande.
En effet, tout admin Unix sérieux utilisera essentiellement dump et restore pour ça (tar, n'est franchement pas adapté pour rechercher un fichier dans une bande de sauvegarde et le restaurer).
Or dump et restore sous Linux ne supportent QUE ext2 et ext3, pas ReiserFS.
Même XFS est mieux de ce côté puisqu'on a les commandes xfsdump et xfsrestore filées avec (comme sur SGI).
Pour JFS, je ne sais pas.
Maintenant, peut-être que je ne suis pas au courant et que les commandes reiserfsdump et reiserfsrestore existent mais je n'en ai pas conaissance. En attendant : ReiserFS = inutilisable en prod, sinon pour des cas particuliers.
En effet, tout admin Unix sérieux utilisera essentiellement dump et restore pour ça (tar, n'est franchement pas adapté pour rechercher un fichier dans une bande de sauvegarde et le restaurer).
Qu'est ce que tu as contre TAR ? Ca marche super bien, et ça a été crée pour faire les sauvegardes. Mais pour en revenir à ton "sérieux" des admins UNIX, je pense que tu oublies aussi tout de suite dump et restore, et tu passes à un logiciel de sauvegarde qui gère les librairies, les revisions, les agents, ...
Pour JFS, je ne sais pas.
Pour JFS tu n'as pour l'instant que ces commandes pour le journal, tu peux utiliser tar pour les datas.
Ben imagine un serveur avec des disques de 73 Go avec entre 100 et 150 comptes sur chaque disque.
Maintenant, imagine un utilisateur apelle la Hotline pour dire "j'ai paumé mon fichier qui s'apelle trucbidule.doc (à peu près) et je ne sais plus trop dans quel répertoire il était. Pouvez vous me restaurer celui d'avant hier".
Ben avec restore -i, c'est facile et vite fait de retrouver le fichier et de le restaurer. Avec tar... bon courage !
Bien sur, y'a des softs pour faire ça mais on tombe rapidement dans le commercial alors que dump + restore, c'est parfait.
Je viens de faire passer mon iBook2 sous Debian (noyau 2.4.16 de benh ) de ext2 à ext3.
l'AVANTAGE principal est la possibilité de faire la manip SANS reformater : c'est fondamental !
(création de la journalisation sur la partition / montée, transformation du ext2 en ext3 dans le /etc/fstab et reboot :) )
La compatibilité avec ext2 en est un autre déterminant
Par Contre ne pas oublier sur platteforme Powerpc de récupérer le dernier Yaboot afin qu'il reconnaisse ext3. Si comme moi vous avez oublié (sic) rebootez sous OSX et remplacez sur votre partition Bootstrap ( en HFS normalement) le Yaboot par celui de la dernière version...
Est ce que quelqu'un a déjà fait des tests de solidité sur ces differents filesystem?
Mon problème étant de savoir lequel permettra un redémarrage le plus rapide après un crash sur des partitions de 400Go. C'est sur une machine avec 12 disque 73Go en Raid 5 découpés en 2 disques logiques, pour un petit serveur de messagerie.
Pour l'instant j'ai mis du reiserfs mais j'ai peut-etre pas fait le bon choix?
En plus certaines applis qui tournent sur ce serveur m'obligent a rester en noyau 2.2.x.
... des partitions de 400Go. C'est sur une machine avec 12 disque 73Go [ ... ] pour un petit serveur de messagerie.
Qu'est-ce que ça serait avec un gros serveur de messagerie ?! :-)
Pour ma boîte qui a 3000 comptes courriel, ce qui commence à faire, la machine a un disque de quelques Go, genre 9 ou 18.
Note que la compatibilité en 2.4 et 2.2 est très élevé !
Sur mon PC de boulot, j'ai une RedHat 7.2. Avant j'avais un 6.2 (noyau 2.2).
Hors sous la RH7.2 je peux faire tourner pratiquement tout les programmes de la 6.2. Au pire pour faire tourner mon ancien serveur web de test, je fais :
$ chroot /mnt/RH6.2 /etc/rc.d/init.d/httpd start
Enfin, j'ai fait tourné sous RH7.2 des programmes (j'ai que les binaires) réalisés à l'époque du 2.0 ! Mais pour çà, il faut ajouter ld.so.1, libc5 et çà fonctionne nyckel.
PS : Je dis que le 2.4 est compatible 2.2 mais pas pour les programmes type mixer de son, lecteur DVD ... évidament.
# petite question
Posté par jpph . Évalué à 1.
Tu as fait les tests des differents filesystems sur la meme partition ?
[^] # Re: petite question
Posté par Qing Liu . Évalué à 1.
de chaque bench, un peu noyé peut-être. Mais bon, c'est
la moindre des choses de respecter ces conditions:)
# XFS et JFS ?
Posté par nicolas garnier . Évalué à 1.
Personnellement je teste JFS sur ma machine, la 1.0.10 est d'ailleurs sortie hier, et je n'ai pas eu de problèmes. Cela fait également plusieurs mois que je fais des install chez nos clients en RedHat-XFS et je n'ai jamais eu aucun problèmes.
JFS : http://www-124.ibm.com/jfs/(...)
XFS : http://oss.sgi.com/projects/xfs/(...)
[^] # Re: XFS et JFS ?
Posté par gege . Évalué à 1.
http://www.linuxgazette.com/issue68/dellomodarme.html(...)
Pour un article plus complet sur les systèmes de fichiers journalisés en général, on pourra se reporter à :
http://www.linuxgazette.com/issue55/florido.html(...)
[^] # Re: XFS et JFS ?
Posté par Qing Liu . Évalué à 1.
dellomodarm parle et fait des tests avec ext3 sous linux
2.2. Un regard un peu attentif sur le tableau des résultat
aurait decelé quelque chose de fantaisiste :), aussi
je n'ai pas (n'ai-je pas) une confiance énorme.
[^] # Re: XFS et JFS ?
Posté par gege . Évalué à 1.
Par contre l'article technique sur les systèmes journalisés est réellement très intéressant.
[^] # Re: XFS et JFS ?
Posté par kael . Évalué à 1.
Sinon ext3 meme si c'est un systeme de fichier journalise un peu simplifie, son point fort c'est qu'il permet de garder la compatibilitée avec ext2 et ca c'est extremement important surtout en production, on peut meme faire la mise a jour sans avoir a passer par les fastidieuses phases de reformatage & co
[^] # Re: XFS et JFS ?
Posté par matiasf . Évalué à 1.
Il supporte aussi la journalisation de donné et çà c'est bon pour la conhérence des données.
> Sinon ext3 meme si c'est un systeme de fichier journalise un peu simplifie.
Je me marre. Avant tout le monde ne jurait que par reiserfs car il y avait plein d'article sur reiserfs. Le développeur principale, Reiser, se répendait dans des :
- reiserfs c'est le meilleur.
- pourquoi utiliser un autre système de fichier journalisé.
- etc...
Pour ext3, les gus bossent dans l'ombre sans faire de communiqués. Au bout d'un moment, les gens pensent d'ext3 est un "systeme de fichier journalise un peu simplifie". N'empéche que lorsqu'il est intégré au noyau Linux, il n'y a pas de problèmes (rien dans le changelog 2.4.16 et 2.4.17-pre1.
En "truc nouveau" ext3 c'est :
- 3 mode de fonctionnement du journal.
- la journalisation des données.
- supporte tout : NFS, quota, lvm, dès sa sortie et pas 8 mois après...
- un journal qui peut-être sur un autre périphérique.
- Du code propre et une implémentation générique qui devrai permettre au développeur ext3 de journir la journalisation à n'importe quel système de fichier (imagine vfat avec journalisation...).
Alors c'est peu-être simple mais c'est efficace et çà MARCHE.
[^] # Re: XFS et JFS ?
Posté par philip . Évalué à 1.
si tu suis les liens proposé tu peux voir que ext3 ne gere pas l'allocation dynamique d'inode, ni les extents.
Mais on peut tres bien vivre sans tout ça :)
[^] # Re: XFS et JFS ?
Posté par nicolas garnier . Évalué à 1.
Parce que ca, on peut peut-être moins facilement vivre sans !
[^] # Re: XFS et JFS ?
Posté par Qing Liu . Évalué à 1.
Non. Suivant la taille des blocks, la limite est la suivante:
Filesystem block size: 1kB 2kB 4kB 8kB
File size limit: 16GB 256GB 2048GB 2048GB
Cf. linux/Documentation/filesystems/ext2.txt. C'est la limite
côté noyau. Pour le côté userland, il faut avoir
une glibc-2.2 ou supérieure, et éventuellement recompiler
les programmes (ls, mv, etc). Mais c'est un peu off-topic :)
Liu
[^] # Re: XFS et JFS ?
Posté par kael . Évalué à 1.
'small is beautifull'
Il est clair que remy card a fait du bon boulot!
[^] # Re: XFS et JFS ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Ça, je me demande comment ça peut être implémenté sans problèmes de performances. Il ne faut pas oublier que le disque dur, il est lent, et les performances globales du système sont donc fortement dépendantes du fs dans pas mal de cas.
- Du code propre et une implémentation générique qui devrai permettre au développeur ext3 de journir la journalisation à n'importe quel système de fichier (imagine vfat avec journalisation...).
Ça existe, c'est NTFS :)
Pour revenir au sujet, ext3 a mis beaucoup plus de temps à être développé que reiserfs, c'est donc normal qu'il soit plus mature à sa sortie (surtout qu'ils ont pu faire attention aux problèmes rencontrés par les autres fs). Et je ne vois pas en quoi les grandes qualités de ext3, qui doivent être soulignées, devraient rabaisser celles de reiserfs.
[^] # Re: XFS et JFS ?
Posté par matiasf . Évalué à 1.
C'est pas évidant. Les gestionnaires de base de données type Oracle, PostgreSQL, etc... qui utilise les transactions, implémentent un équivalent de journalisation de données sans impacte significatif sur les performances (parfois c'est même plus rapide !).
Mais les benchmarks montre d'ext3 en mode order reste très performants. Perso, le gain en sécurité compense largement la petite perte de performance (mais les goûts et les couleurs...).
> Et je ne vois pas en quoi les grandes qualités de ext3, qui doivent être soulignées, devraient rabaisser celles de reiserfs.
C'est claire.
Et je suis désolé si les utilisateurs ou développeurs de ReiserFS l'ont mal pris.
J'ai lus plusieurs trucs sur ReiserFS et il contient des inovations technologiques remarquables (principalement sur la gestion des petits fichiers).
Le post que j'ai mis, était un post énervé. Enervé de lire qu'ext3 était un gestionnaire de fichier "simplifié".
Je pense qu'il ne doit pas être "simple" de faire un système de fichier journalisé équivalent à ext3 (méta-donnée, donnée, compatibilité ext2/ext3 ascendante et descendante, cohérent donc rapidement au point, etc...) et le tout parfaitement intégré au noyau Linux (NFS, Quota, ACL (pas encore en standars :o) ))..
Enfin, j'apprécie le free software et vois toujours d'un bon oeil la cocurrence (ReiserFS/ext3/XFS/.., Gnome/KDE...).
Go ReiserFS.
Go ext3.
[^] # Re: XFS et JFS ?
Posté par nicolas garnier . Évalué à 1.
De toutes façon, un petit coup de vi pour placer un .rej et ca roule.
[^] # Re: XFS et JFS ?
Posté par Qing Liu . Évalué à 1.
trouve des tests assez exhaustifs sur le site de namesys
http://www.namesys.com/.(...) J'ai touché un petit mot sur
jfs (1.0.9) dans la partie dbench. dbench (ou jfs) s'est même
vautré pendant le test sur jfs.
[^] # Re: XFS et JFS ?
Posté par VACHOR (site web personnel) . Évalué à 1.
# deux petites questions...
Posté par bobert . Évalué à 1.
1. qu'est-ce qu'il ressortirait d'une comparaison à la louche entre reiserFS,ext3 et NTFS ?
2. j'ai testé récemment l'install d'une mdk8.1 avec le noyo d'origine (euh, je suis pas sur la bécane, mais à vue de nez un 2.4.3 ??), et pour la première fois en passant à reiserFS pour *toutes* mes partitions. J'ai eu de gros pb de temps de latence (peux pas en dire plus, j'avais vraiment pas le temps de chercher d'où ca venait). J'imagine naïvement qu'au premier reboot, il y a eu création du journal du filesystem de chaque partition (?) donc ca aurait pu être une explication, mais le problème a persisté bien après. J'ai refait l'install en choisissant cette fois ext3, et je n'ai pas eu ce problème. Y'en a qui peuvent trouver le diagnostic, après cette description à 2 balles ???!? (non, c'est pas un problème de swap, ca j'ai vérifié)
A+
eul'Bob
# Journalisation des données
Posté par Romuald Delavergne . Évalué à 1.
Cette fonctionnalité réduit par deux les performances en écriture mais est néanmoins très intéressante pour les données sensibles. Car contrairement à ce que croient la plupart des gens, ce n'est pas parce que l'on a un système de fichiers journalisé que les dernières écritures seront saines après un crash de la machine. Le système de fichiers journalisé assure seulement un boot rapide en se passant du fsck.
[^] # Re: Journalisation des données
Posté par Gaël Le Mignot . Évalué à 1.
Le mode par défaut (data=ordered) apporte la fiabilité des données, mais avec un coût en performances beaucoup plus faible que le mode de journalisation des données (data=journal)
[^] # Re: Journalisation des données
Posté par Olivier Jeannet . Évalué à 1.
Il assure en fait la cohérence de la structure du système de fichier, c'est à dire qu'on ne risque pas de se retrouver avec des répertoires incomplets ou des inodes qui pointent n'importe où, des bouts de fichiers pas référencés, etc...
Par contre on peut très bien perdre les dernières données écrites dans un fichier.
Je recommande la lecture de l'interview de Theo de Raadt (OpenBSD), passée ici il y a quelques jours, et il donne en référence un document intéressant à lire :
"Journaling versus soft updates: asynchronous meta-data protection in file systems" http://www.usenix.org/publications/library/proceedings/usenix2000/g(...)
Il a donné cette référence en parlant de la définition du dernier état "bon" ou "stable" d'un système de fichier, en fait on peut en concevoir plusieurs.
# ENORME défaut de ReiserFS et avantage de ext3...
Posté par Serge Rossi (site web personnel) . Évalué à 1.
En effet, tout admin Unix sérieux utilisera essentiellement dump et restore pour ça (tar, n'est franchement pas adapté pour rechercher un fichier dans une bande de sauvegarde et le restaurer).
Or dump et restore sous Linux ne supportent QUE ext2 et ext3, pas ReiserFS.
Même XFS est mieux de ce côté puisqu'on a les commandes xfsdump et xfsrestore filées avec (comme sur SGI).
Pour JFS, je ne sais pas.
Maintenant, peut-être que je ne suis pas au courant et que les commandes reiserfsdump et reiserfsrestore existent mais je n'en ai pas conaissance. En attendant : ReiserFS = inutilisable en prod, sinon pour des cas particuliers.
[^] # Re: ENORME défaut de ReiserFS et avantage de ext3...
Posté par nicolas garnier . Évalué à 1.
Qu'est ce que tu as contre TAR ? Ca marche super bien, et ça a été crée pour faire les sauvegardes. Mais pour en revenir à ton "sérieux" des admins UNIX, je pense que tu oublies aussi tout de suite dump et restore, et tu passes à un logiciel de sauvegarde qui gère les librairies, les revisions, les agents, ...
Pour JFS, je ne sais pas.
Pour JFS tu n'as pour l'instant que ces commandes pour le journal, tu peux utiliser tar pour les datas.
[^] # Re: ENORME défaut de ReiserFS et avantage de ext3...
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Ben imagine un serveur avec des disques de 73 Go avec entre 100 et 150 comptes sur chaque disque.
Maintenant, imagine un utilisateur apelle la Hotline pour dire "j'ai paumé mon fichier qui s'apelle trucbidule.doc (à peu près) et je ne sais plus trop dans quel répertoire il était. Pouvez vous me restaurer celui d'avant hier".
Ben avec restore -i, c'est facile et vite fait de retrouver le fichier et de le restaurer. Avec tar... bon courage !
Bien sur, y'a des softs pour faire ça mais on tombe rapidement dans le commercial alors que dump + restore, c'est parfait.
(ceci n'est pas un exemple théorique :-)
# ext3 powerpc portable
Posté par AnAxAgore . Évalué à 1.
l'AVANTAGE principal est la possibilité de faire la manip SANS reformater : c'est fondamental !
(création de la journalisation sur la partition / montée, transformation du ext2 en ext3 dans le /etc/fstab et reboot :) )
La compatibilité avec ext2 en est un autre déterminant
Par Contre ne pas oublier sur platteforme Powerpc de récupérer le dernier Yaboot afin qu'il reconnaisse ext3. Si comme moi vous avez oublié (sic) rebootez sous OSX et remplacez sur votre partition Bootstrap ( en HFS normalement) le Yaboot par celui de la dernière version...
et voilà ;)
# Et le Down time?
Posté par Gauthier (Mastodon) . Évalué à 1.
Mon problème étant de savoir lequel permettra un redémarrage le plus rapide après un crash sur des partitions de 400Go. C'est sur une machine avec 12 disque 73Go en Raid 5 découpés en 2 disques logiques, pour un petit serveur de messagerie.
Pour l'instant j'ai mis du reiserfs mais j'ai peut-etre pas fait le bon choix?
En plus certaines applis qui tournent sur ce serveur m'obligent a rester en noyau 2.2.x.
[^] # Re: Et le Down time?
Posté par Olivier Jeannet . Évalué à 1.
Qu'est-ce que ça serait avec un gros serveur de messagerie ?! :-)
Pour ma boîte qui a 3000 comptes courriel, ce qui commence à faire, la machine a un disque de quelques Go, genre 9 ou 18.
[^] # Re: Et le Down time?
Posté par matiasf . Évalué à 1.
ext3 est disponible pour 2.2 :
ftp://ftp.beta.redhat.com/pub/ext3/(...)
Pour plus d'info c'est ici :
http://ha.redhat.com/news/Ext3_Program.txt(...)
Note que la compatibilité en 2.4 et 2.2 est très élevé !
Sur mon PC de boulot, j'ai une RedHat 7.2. Avant j'avais un 6.2 (noyau 2.2).
Hors sous la RH7.2 je peux faire tourner pratiquement tout les programmes de la 6.2. Au pire pour faire tourner mon ancien serveur web de test, je fais :
$ chroot /mnt/RH6.2 /etc/rc.d/init.d/httpd start
Enfin, j'ai fait tourné sous RH7.2 des programmes (j'ai que les binaires) réalisés à l'époque du 2.0 ! Mais pour çà, il faut ajouter ld.so.1, libc5 et çà fonctionne nyckel.
PS : Je dis que le 2.4 est compatible 2.2 mais pas pour les programmes type mixer de son, lecteur DVD ... évidament.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.