Bonjour,
Je suis en train de réaliser un CD à base d'une Debian pour automatiser l'installer de nos serveurs. A ce propos je peux vous soumettre quelques liens si ça vous interesse comme:
- http://www.geocities.com/potato.geo/bootlinuxcd.html(...)
- http://www.tldp.org/HOWTO/Bootdisk-HOWTO/(...)
- http://chninkel.net/docs/doku.php?id=howto:livecd(...)
Le dernier lien est la documentation que je suis en train d'écrire sur le sujet, en francais.
Mon CD Bootant maintenant correctement, j'en suis à l'étape partitionnement du disque. J'ai cherché des outils pour faire cette opération en ligne de commande et j'ai découvert GNU Parted, je ne pouvais rever mieux ! Seul petit probleme il ne supporte pas encore la création de partition ext3.
Est ce que vous connaitriez un outil en ligne de commande, supportant la création de partition ext3 ?
Merci d'avance, je vais continuer à éplucher les 8 000 000 000 de pages indéxées par google pour ma part :)
--
Guillaume
Journal Parted et ext3
18
mar.
2005
# mke2fs -j /dev/hd
Posté par freeture . Évalué à 2.
[^] # tune2fs -j /dev/hd
Posté par Mouns (site web personnel) . Évalué à 3.
une ext3 est une ext2 + qq features.
pour activer le journal et transformer une ext2 en ext3, il suffit de faire un tune2fs -j
et avec ce "truc", plus besoin de reformater pour migrer :)
# arf :'(
Posté par DjinnS . Évalué à 2.
Je pensais à creer directement (avec les options de parted) le systeme en ext3 alors que je peux effectivement le formater apres ...
Merci, je me retire la tete basse :(
--
Guillaume
[^] # Re: arf :'(
Posté par Yusei (Mastodon) . Évalué à 2.
# Il y a un truc qui m'inquiète...
Posté par Anonyme . Évalué à 5.
Je sais que certains sur la tribune ont rencontré les mêmes problèmes, visiblement tous sous Mandrakelinux. Attention, je n'ai jamais dit que c'était Mandrakelinux le problème, c'est juste que pour l'instant, c'est le seul point commun entre tous nos crash, avec le système ext3fs. À ce sujet, il apparaît que Red Hat patche fortement ext3fs, mais je n'ai encore qu'1 mois de backend de Fedora, donc ce n'est pas suffisant pour juger d'une meilleure stabilité.
L'ironie dans l'histoire, c'est qu'en presque 10 ans de NTFS, je n'avais jamais connu autant de pertes de données (jamais à titre personnel), même en incluant tous les problèmes rencontrés chez mes clients (1 seule perte de données, liée à un crash disque matériel). Le système de fichiers est pour moi LE truc qui DOIT être bétonné.
Tout ceci pour dire que je me demande encore pourquoi un système de fichiers aussi plantogène est encore utilisé sur un serveur, à moins que le problème ne soit pas lié à ext3fs mais à Mandrakelinux ? Pour l'instant je ne suis pas plus avancé, mais il est évident que pour ma part, ext3fs (sous Mandrakelinux ?) est inexploitable en environnement professionnel.
Décidement, vivement que reiserfs4 arrive !
[^] # Re: Il y a un truc qui m'inquiète...
Posté par Romuald Delavergne . Évalué à 2.
Le problème que tu as rencontré, tu l'auras donc avec tous les systèmes de fichiers journalisé car l'écriture effective sur le disque est désynchronisée avec la commande de copie contrairement au DOS. Par contre, un moyen simple de réduire le risque de perte de données est de diminuer le paramètre 'bdflush' du noyau. Par défaut le noyau peut copier réellement sur le disque seulement au bout de 30 secondes (cf /usr/src/linux/Documentation/sysctl/vm.txt).
[^] # Re: Il y a un truc qui m'inquiète...
Posté par Vivi (site web personnel) . Évalué à 3.
sauf que ext3 (selon une option au montage) peut également assurer la cohérence des données :
cf ce thread où un gars fait des tests en coupant le courant pendant l'écriture.
Résultats : pratiquement pas de pertes avec ext3 mais par contre reiserfs était tellement dans les chous qu'il ne pouvait plus booter.
https://www.redhat.com/archives/fedora-list/2004-July/msg00418.html(...)
[^] # Re: Il y a un truc qui m'inquiète...
Posté par Michel Pastor . Évalué à 1.
Alors dire que ext3 est plantogène je pense que c'est un peu exagéré d'autant que tu trouvera forcément des témoignages de crash mais surement plus rarement des témoignage d'absence de crash...
[^] # Re: Il y a un truc qui m'inquiète...
Posté par Frédéric COIFFIER . Évalué à 1.
La version courante fonctionne très bien et je n'ai jamais eu de problèmes avec (pour des besoins persos, je précise). D'ailleurs, je regrette d'avoir utilisé EXT3 sur mon PC portable.
A ce propos, j'avais une question : le check filesystem périodique de EXT3 est-il une spécificité de ce file system ou devrait-il exister aussi pour ReiserFS ? Car de temps en temps, le démarrage avec EXT3 prend bien 5-10 min à cause du check filesystem alors que je n'ai jamais vu de check filesystem sur ReiserFS...
[^] # Re: Il y a un truc qui m'inquiète...
Posté par Michel Pastor . Évalué à 1.
[^] # Re: Il y a un truc qui m'inquiète...
Posté par fabb . Évalué à 1.
C'est paramétrable. Faire "man tune2fs".
Moi je le laisse. Une vérification forcée de temps à autre ne peut pas faire de mal.
Pour voir la configuration actuelle, utiliser dumpe2fs.
Exemple :
$ dumpe2fs /dev/hde1
Mount count: 2
Maximum mount count: 35
Last checked: Thu Mar 17 08:14:32 2005
Check interval: 15552000 (6 months)
Next check after: Tue Sep 13 09:14:32 2005
[^] # Re: Il y a un truc qui m'inquiète...
Posté par fabb . É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/...".
# dpsyco & fal
Posté par alexissoft . Évalué à 1.
- dpsyco : Il permet (si je comprend bien) de faire un "fork" d'une debian personnalisée avec ensuite de la maintenance comme l'interfacage avec cfengine2 et autres...
- FAL : Permet d'installer automatiquement une debian à partir d'options données sur un serveur NFS
Je te recommande d'utiliser un des deux outils, ça t'évitera de te tracasser :)
Sinon, utilise cfdisk /dev/hdX pour le partitionnement et mkfs.ext3 /dev/hdXY pour faire le filesystem.
Bonne chance
[^] # Re: dpsyco & fal
Posté par Prosper . Évalué à 3.
ca s appelle F-A-I : http://www.informatik.uni-koeln.de/fai/(...)
[^] # Re: dpsyco & fal
Posté par DjinnS . Évalué à 1.
Ca permet au la plus stupide des personnes d'installer un de nos serveurs, pas besoin que ce soit un gars qui connaisse le processus.
Merci pour l'info tout de meme, c'est un truc tres interessant :)
# mondo
Posté par Gilles Mocellin . Évalué à 1.
Idéal pour un master.
J'ai eu quelque soucis avec du LVM sous Mandrakelinux, mais ça a l'air pas mal utilisé, et donc au point sous Debian.
C'est par là :
http://www.mondorescue.org/(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.