--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/00f001caf446$040e1400$0c2a3c00$@free.fr
Et s'il ne réussit pas à démarrer depuis hd0, il switch sur hd1.
Ben non puisque - toujours sauf erreur de ma part - quel que soit le disque physique que le BIOS réussit à amorcer, c'est lui qui devient hd0.
Ta perception du fallback est basée sur la défaillance d'un disque qui plus reconnu par le BIOS. Il y a des défaillances disque ou celui ci est reconnu par le bios mais plus bootable ou kernel panic. Dans ce cas l'option fallback joue son role.
-- Daniel
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 18/06/2010 20:03, Pascal Hambourg a écrit :
[...]
Et s'il ne réussit pas à démarrer depuis hd0, il switch sur hd1.
Ben non puisque - toujours sauf erreur de ma part - quel que soit le
disque physique que le BIOS réussit à amorcer, c'est lui qui devient hd0.
Ta perception du fallback est basée sur la défaillance d'un disque qui
plus reconnu par le BIOS. Il y a des défaillances disque ou celui ci est
reconnu par le bios mais plus bootable ou kernel panic. Dans ce cas
l'option fallback joue son role.
--
Daniel
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C1BD31C.2050502@tootai.net
Et s'il ne réussit pas à démarrer depuis hd0, il switch sur hd1.
Ben non puisque - toujours sauf erreur de ma part - quel que soit le disque physique que le BIOS réussit à amorcer, c'est lui qui devient hd0.
Ta perception du fallback est basée sur la défaillance d'un disque qui plus reconnu par le BIOS. Il y a des défaillances disque ou celui ci est reconnu par le bios mais plus bootable ou kernel panic. Dans ce cas l'option fallback joue son role.
-- Daniel
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Vincent Danjean
On 18/06/2010 10:12, daniel huhardeaux wrote:
Le 18/06/2010 07:59, Vincent Danjean a écrit :
[...] > Cependant si je supprime le premier disque impossible de booter !?! Dans tous les cas, je crois que le initrd refuse de démarrer le RAID par défaut si tous les disques ne sont pas là. [...]
Si le premier disque est retiré la machine démarrera sur le second.
Ici, pour grub, il n'y a pas de RAID qui intervienne. C'est de la redondance/duplication manuelle.
Dans mon message précédent, je ne parlais pas du démarrage de grub (qui, si la config et l'installation sont dupliqués correctement, alors grub démarrera sur l'un ou l'autre des disques). Je parlais du fait que, d'après mes souvenirs (ie je n'ai pas vérifié), la config par défaut de mdadm (dans le initrd et sur le système) est de ne démarrer (rendre disponible /dev/mdX) le RAID que lorsque tous les disques sont présents. Le démarrage du raid logiciel en mode dégradé est possible mais il faut soit changer la config par défaut, soit intervenir manuellement. Si je me souviens bien, cette config par défaut avait été choisie pour éviter de marquer un disque un peu lent à démarrer comme FAILED alors qu'il aurait juste fallu attendre un peu.
L'intérêt du Raid1 serait vraiment moindre s'il ne démarrait pas sur le second disque sans intervention humaine.
Ça dépend où tu places les priorités. Pour ma part, je ne cherche pas le 24/24 avec le RAID mais la sécurité de mes données. Si un disque du RAID tombe en panne, je préfère être prévenu tout de suite. Si, au démarrage, un des disques n'est pas là, je préfère devoir intervenir manuellement pour observer ce qui se passe, pour trouver la raison, plutôt que booter à tout prix. Ça me rappelle une expérience d'un centre de recherche où, à l'occasion d'une intervention, un électricien avait arrêter la clim de la salle machine. Évidemment, la température est montée et, au bout d'un moment, un disque de la baie RAID5 est tombé. Comme il y avait un spare de dispo, le système a automatiquement commencé à le remplir pour remplacer le disque tombé => plein d'activité disque qui ont encore fait monter la température de la baie RAID5 => plusieurs disques sont tombés. La baie était irrécupérable. Il a fallu changer plusieurs disques et repartir d'une sauvegarde sur bande antérieure. C'est un exemple où il aurait mieux fallu tout arrêter plutôt que continuer. Mais le système automatique n'était pas capable d'analyser la cause véritable du problème : l'arrêt de la clim.
A+ Vincent
-- Vincent Danjean GPG key ID 0x9D025E87 GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
On 18/06/2010 10:12, daniel huhardeaux wrote:
Le 18/06/2010 07:59, Vincent Danjean a écrit :
[...]
> Cependant si je supprime le premier disque impossible de booter !?!
Dans tous les cas, je crois que le initrd refuse de démarrer le RAID
par défaut si tous les disques ne sont pas là. [...]
Si le premier disque est retiré la machine démarrera sur le second.
Ici, pour grub, il n'y a pas de RAID qui intervienne. C'est de la
redondance/duplication manuelle.
Dans mon message précédent, je ne parlais pas du démarrage de grub
(qui, si la config et l'installation sont dupliqués correctement, alors
grub démarrera sur l'un ou l'autre des disques).
Je parlais du fait que, d'après mes souvenirs (ie je n'ai pas vérifié),
la config par défaut de mdadm (dans le initrd et sur le système) est de
ne démarrer (rendre disponible /dev/mdX) le RAID que lorsque tous les
disques sont présents. Le démarrage du raid logiciel en mode dégradé
est possible mais il faut soit changer la config par défaut, soit
intervenir manuellement.
Si je me souviens bien, cette config par défaut avait été choisie pour
éviter de marquer un disque un peu lent à démarrer comme FAILED alors
qu'il aurait juste fallu attendre un peu.
L'intérêt du Raid1 serait vraiment moindre s'il ne démarrait pas sur le
second disque sans intervention humaine.
Ça dépend où tu places les priorités. Pour ma part, je ne cherche pas
le 24/24 avec le RAID mais la sécurité de mes données. Si un disque du
RAID tombe en panne, je préfère être prévenu tout de suite. Si, au
démarrage, un des disques n'est pas là, je préfère devoir intervenir
manuellement pour observer ce qui se passe, pour trouver la raison,
plutôt que booter à tout prix.
Ça me rappelle une expérience d'un centre de recherche où, à l'occasion
d'une intervention, un électricien avait arrêter la clim de la salle
machine. Évidemment, la température est montée et, au bout d'un moment,
un disque de la baie RAID5 est tombé. Comme il y avait un spare de dispo,
le système a automatiquement commencé à le remplir pour remplacer le
disque tombé => plein d'activité disque qui ont encore fait monter la
température de la baie RAID5 => plusieurs disques sont tombés. La
baie était irrécupérable. Il a fallu changer plusieurs disques et
repartir d'une sauvegarde sur bande antérieure.
C'est un exemple où il aurait mieux fallu tout arrêter plutôt que
continuer. Mais le système automatique n'était pas capable d'analyser
la cause véritable du problème : l'arrêt de la clim.
A+
Vincent
--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C20AA7A.1000301@free.fr
[...] > Cependant si je supprime le premier disque impossible de booter !?! Dans tous les cas, je crois que le initrd refuse de démarrer le RAID par défaut si tous les disques ne sont pas là. [...]
Si le premier disque est retiré la machine démarrera sur le second.
Ici, pour grub, il n'y a pas de RAID qui intervienne. C'est de la redondance/duplication manuelle.
Dans mon message précédent, je ne parlais pas du démarrage de grub (qui, si la config et l'installation sont dupliqués correctement, alors grub démarrera sur l'un ou l'autre des disques). Je parlais du fait que, d'après mes souvenirs (ie je n'ai pas vérifié), la config par défaut de mdadm (dans le initrd et sur le système) est de ne démarrer (rendre disponible /dev/mdX) le RAID que lorsque tous les disques sont présents. Le démarrage du raid logiciel en mode dégradé est possible mais il faut soit changer la config par défaut, soit intervenir manuellement. Si je me souviens bien, cette config par défaut avait été choisie pour éviter de marquer un disque un peu lent à démarrer comme FAILED alors qu'il aurait juste fallu attendre un peu.
L'intérêt du Raid1 serait vraiment moindre s'il ne démarrait pas sur le second disque sans intervention humaine.
Ça dépend où tu places les priorités. Pour ma part, je ne cherche pas le 24/24 avec le RAID mais la sécurité de mes données. Si un disque du RAID tombe en panne, je préfère être prévenu tout de suite. Si, au démarrage, un des disques n'est pas là, je préfère devoir intervenir manuellement pour observer ce qui se passe, pour trouver la raison, plutôt que booter à tout prix. Ça me rappelle une expérience d'un centre de recherche où, à l'occasion d'une intervention, un électricien avait arrêter la clim de la salle machine. Évidemment, la température est montée et, au bout d'un moment, un disque de la baie RAID5 est tombé. Comme il y avait un spare de dispo, le système a automatiquement commencé à le remplir pour remplacer le disque tombé => plein d'activité disque qui ont encore fait monter la température de la baie RAID5 => plusieurs disques sont tombés. La baie était irrécupérable. Il a fallu changer plusieurs disques et repartir d'une sauvegarde sur bande antérieure. C'est un exemple où il aurait mieux fallu tout arrêter plutôt que continuer. Mais le système automatique n'était pas capable d'analyser la cause véritable du problème : l'arrêt de la clim.
A+ Vincent
-- Vincent Danjean GPG key ID 0x9D025E87 GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
