j'essaie de comprendre ce qui se passe lors du boot d'un système en raid1
logiciel sur la partition root, mais il reste un certain nombre de zones
d'ombres !
Ce que j'ai compris, d'après les pages de man de md, mdadm, grub, etc. :
1) le bios boot
2) grub boot : il lit le noyau et l'initramfs
Q : comment fait-il pour lire le noyau et l'initrd.img sur de raid1 ? Ou
alors chaque disque composant l'ARRAY peut être aussi lu directement en
ext3 (ext3 par exemple) ?
3?) la détection automatique dans le noyau des partitins
linux-raid-autodetect intervient-elle jamais ?
4) dans l'initramfs, un script init-premount est appelé qui passe la main
à udev
5) udev applique ses règles, dont :
5.1) /etc/udev/rules.d/65-persistant-storage.rules : exporte des infos en
variables d'environnement sur les différents périphériques blocs, en
particulier cette règle :
ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
Là tout commentaire est le bienvenu.
5.2) /etc/udev/rules.d/85-mdadm.rules : lance /sbin/mdadm --assemble
--scan --no-degraded dès qu'un device de type block dont le ID_FS_TYPE =
'linux_raid*' est détecté par udev
la règle est SUBSYSTEM=="block", ACTION=="add|change",
ENV{ID_FS_TYPE}=="linux_raid*", \
RUN+="watershed /sbin/mdadm --assemble --scan --no-degraded"
Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3]
alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais
j'ai besoin d'une petite explication...
6) mdadm prend la main :
/sbin/mdadm --assemble --scan --no-degraded
Si j'ai bien lu, mdadm se base d'une part sur /etc/mdadm.conf pour savoir
quels array assembler, et sur le superblock pour repérer les partitions
correspondantes (basé sur les UUID).
Le rapport entre type de partition fd linux-raid-autodetect, superblock,
flag raid (voir man parted) m'échappe un peu. Un superblock persitant raid
peut-il est écrit sur une partition de type linux, ou est-il nécessaire
qu'elle soit de type fd ?
7) root est monté et le système démarre
Voilà, tout ça reste malgré tout assez nébuleux pour moi. Tout commentaire
sera le bienvenu !
Franck
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Yves F. Barbier
a écrit :
Bonjour,
j'essaie de comprendre ce qui se passe lors du boot d'un système en raid1 logiciel sur la partition root, mais il reste un certain nombre de zones d'ombres !
Ce que j'ai compris, d'après les pages de man de md, mdadm, grub, etc. :
1) le bios boot
2) grub boot : il lit le noyau et l'initramfs
Q : comment fait-il pour lire le noyau et l'initrd.img sur de raid1 ? Ou
sèpô
alors chaque disque composant l'ARRAY peut être aussi lu directement en ext3 (ext3 par exemple) ?
oui; c'est ce qui permet de continuer à utiliser un array en mode degraded
3?) la détection automatique dans le noyau des partitins linux-raid-autodetect intervient-elle jamais ?
si, parce que si tu interverti tes HDz, l'array continue à être correctement détecté
4) dans l'initramfs, un script init-premount est appelé qui passe la main à udev
5) udev applique ses règles, dont :
5.1) /etc/udev/rules.d/65-persistant-storage.rules : exporte des infos en variables d'environnement sur les différents périphériques blocs, en particulier cette règle : ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
apparemment tu n'es pas en Sarge. Ca serait bien de le préciser...
Là tout commentaire est le bienvenu.
5.2) /etc/udev/rules.d/85-mdadm.rules : lance /sbin/mdadm --assemble --scan --no-degraded dès qu'un device de type block dont le ID_FS_TYPE > 'linux_raid*' est détecté par udev la règle est SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", RUN+="watershed /sbin/mdadm --assemble --scan --no-degraded"
Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3] alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais j'ai besoin d'une petite explication...
l'option 'scan' scanne les partitions pour récupérer le membres de l'array et leur ordre; elle n'est donc lancée qu'une fois par array
....
Le rapport entre type de partition fd linux-raid-autodetect, superblock, flag raid (voir man parted) m'échappe un peu. Un superblock persitant raid
qu'est-ce que 'parted' vient faire ici? C'est un pgm qui permet de changer la taille des partitions.
peut-il est écrit sur une partition de type linux, ou est-il nécessaire qu'elle soit de type fd ?
c'est le type 'fd' qui lance l'option 'scan' de mdadm (et permet, même si les HDz ont été intervertis, de les réordonner)
ça confine à la masturbation intellectuelle: si tu veux *exactement* savoir comment ça marche, il suffit de charger le source du kernel et d'examiner les fichiers concernés. -- The mark of the immature man is that he wants to die nobly for a cause, while the mark of a mature man is that he wants to live humbly for one. -- Wilhelm Stekel
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
alci@mecadu.org a écrit :
Bonjour,
j'essaie de comprendre ce qui se passe lors du boot d'un système en raid1
logiciel sur la partition root, mais il reste un certain nombre de zones
d'ombres !
Ce que j'ai compris, d'après les pages de man de md, mdadm, grub, etc. :
1) le bios boot
2) grub boot : il lit le noyau et l'initramfs
Q : comment fait-il pour lire le noyau et l'initrd.img sur de raid1 ? Ou
sèpô
alors chaque disque composant l'ARRAY peut être aussi lu directement en
ext3 (ext3 par exemple) ?
oui; c'est ce qui permet de continuer à utiliser un array en mode degraded
3?) la détection automatique dans le noyau des partitins
linux-raid-autodetect intervient-elle jamais ?
si, parce que si tu interverti tes HDz, l'array continue à être correctement
détecté
4) dans l'initramfs, un script init-premount est appelé qui passe la main
à udev
5) udev applique ses règles, dont :
5.1) /etc/udev/rules.d/65-persistant-storage.rules : exporte des infos en
variables d'environnement sur les différents périphériques blocs, en
particulier cette règle :
ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
apparemment tu n'es pas en Sarge. Ca serait bien de le préciser...
Là tout commentaire est le bienvenu.
5.2) /etc/udev/rules.d/85-mdadm.rules : lance /sbin/mdadm --assemble
--scan --no-degraded dès qu'un device de type block dont le ID_FS_TYPE > 'linux_raid*' est détecté par udev
la règle est SUBSYSTEM=="block", ACTION=="add|change",
ENV{ID_FS_TYPE}=="linux_raid*",
RUN+="watershed /sbin/mdadm --assemble --scan --no-degraded"
Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3]
alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais
j'ai besoin d'une petite explication...
l'option 'scan' scanne les partitions pour récupérer le membres de l'array
et leur ordre; elle n'est donc lancée qu'une fois par array
....
Le rapport entre type de partition fd linux-raid-autodetect, superblock,
flag raid (voir man parted) m'échappe un peu. Un superblock persitant raid
qu'est-ce que 'parted' vient faire ici? C'est un pgm qui permet de changer
la taille des partitions.
peut-il est écrit sur une partition de type linux, ou est-il nécessaire
qu'elle soit de type fd ?
c'est le type 'fd' qui lance l'option 'scan' de mdadm (et permet, même si
les HDz ont été intervertis, de les réordonner)
ça confine à la masturbation intellectuelle: si tu veux *exactement* savoir
comment ça marche, il suffit de charger le source du kernel et d'examiner
les fichiers concernés.
--
The mark of the immature man is that he wants to die nobly for a cause,
while the mark of a mature man is that he wants to live humbly for one.
-- Wilhelm Stekel
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
j'essaie de comprendre ce qui se passe lors du boot d'un système en raid1 logiciel sur la partition root, mais il reste un certain nombre de zones d'ombres !
Ce que j'ai compris, d'après les pages de man de md, mdadm, grub, etc. :
1) le bios boot
2) grub boot : il lit le noyau et l'initramfs
Q : comment fait-il pour lire le noyau et l'initrd.img sur de raid1 ? Ou
sèpô
alors chaque disque composant l'ARRAY peut être aussi lu directement en ext3 (ext3 par exemple) ?
oui; c'est ce qui permet de continuer à utiliser un array en mode degraded
3?) la détection automatique dans le noyau des partitins linux-raid-autodetect intervient-elle jamais ?
si, parce que si tu interverti tes HDz, l'array continue à être correctement détecté
4) dans l'initramfs, un script init-premount est appelé qui passe la main à udev
5) udev applique ses règles, dont :
5.1) /etc/udev/rules.d/65-persistant-storage.rules : exporte des infos en variables d'environnement sur les différents périphériques blocs, en particulier cette règle : ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
apparemment tu n'es pas en Sarge. Ca serait bien de le préciser...
Là tout commentaire est le bienvenu.
5.2) /etc/udev/rules.d/85-mdadm.rules : lance /sbin/mdadm --assemble --scan --no-degraded dès qu'un device de type block dont le ID_FS_TYPE > 'linux_raid*' est détecté par udev la règle est SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", RUN+="watershed /sbin/mdadm --assemble --scan --no-degraded"
Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3] alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais j'ai besoin d'une petite explication...
l'option 'scan' scanne les partitions pour récupérer le membres de l'array et leur ordre; elle n'est donc lancée qu'une fois par array
....
Le rapport entre type de partition fd linux-raid-autodetect, superblock, flag raid (voir man parted) m'échappe un peu. Un superblock persitant raid
qu'est-ce que 'parted' vient faire ici? C'est un pgm qui permet de changer la taille des partitions.
peut-il est écrit sur une partition de type linux, ou est-il nécessaire qu'elle soit de type fd ?
c'est le type 'fd' qui lance l'option 'scan' de mdadm (et permet, même si les HDz ont été intervertis, de les réordonner)
ça confine à la masturbation intellectuelle: si tu veux *exactement* savoir comment ça marche, il suffit de charger le source du kernel et d'examiner les fichiers concernés. -- The mark of the immature man is that he wants to die nobly for a cause, while the mark of a mature man is that he wants to live humbly for one. -- Wilhelm Stekel
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
alci
Bonjour,
Le mercredi 16 janvier 2008 à 18:59 +0100, Jean-Yves F. Barbier a écrit :
> alors chaque disque composant l'ARRAY peut être aussi lu directement en > ext3 (ext3 par exemple) ?
oui; c'est ce qui permet de continuer à utiliser un array en mode degraded
Et c'est donc comme ça que grub lit le noyau et l'initrd, du coup.
> 3?) la détection automatique dans le noyau des partitins > linux-raid-autodetect intervient-elle jamais ?
si, parce que si tu interverti tes HDz, l'array continue à être correctement détecté
Euh, non je ne crois pas... En fait le man de mdadm précise que l'autodetection par le noyau n'intervient que si md est intégré dans le noyau (pas dans les modules)... Donc je pense que l'autodetection "in kernel" n'intervient pas. En plus les changelog de mdadm précisent que ces méthode est 'deprecated' depuis au moins 2006 et que la voie à suivre et l'utilisation de mdadm (userland) depuis l'initramfs.
> 4) dans l'initramfs, un script init-premount est appelé qui passe la main > à udev > > 5) udev applique ses règles, dont : > > 5.1) /etc/udev/rules.d/65-persistant-storage.rules : exporte des infos en > variables d'environnement sur les différents périphériques blocs, en > particulier cette règle : > ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
apparemment tu n'es pas en Sarge. Ca serait bien de le préciser...
Désolé.
> Là tout commentaire est le bienvenu. > > 5.2) /etc/udev/rules.d/85-mdadm.rules : lance /sbin/mdadm --assemble > --scan --no-degraded dès qu'un device de type block dont le ID_FS_TYPE > > 'linux_raid*' est détecté par udev > la règle est SUBSYSTEM=="block", ACTION=="add|change", > ENV{ID_FS_TYPE}=="linux_raid*", > RUN+="watershed /sbin/mdadm --assemble --scan --no-degraded" > > Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3] > alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais > j'ai besoin d'une petite explication...
l'option 'scan' scanne les partitions pour récupérer le membres de l'array et leur ordre; elle n'est donc lancée qu'une fois par array
Elle lancée par udev, non ? donc si udev lance la commande plusieurs fois, elle intervient plusieurs fois. La question est donc de savoir si il y a un évènement par partition et si cela lance la commande à chaque fois...
....
> Le rapport entre type de partition fd linux-raid-autodetect, superblock, > flag raid (voir man parted) m'échappe un peu. Un superblock persitant raid
qu'est-ce que 'parted' vient faire ici? C'est un pgm qui permet de changer la taille des partitions.
La taille mais aussi les flag, je cite :
set partition flag state change the state of the flag on partition to state. Flags supported are: "boot", "root", "swap", "hidden", "raid", "lvm", "lba" and "palo". state should be either "on" or "off"
Il existe donc un flag "raid", et je ne comprends pas son rapport avec le type de partition 'fd'.
> peut-il est écrit sur une partition de type linux, ou est-il nécessaire > qu'elle soit de type fd ?
c'est le type 'fd' qui lance l'option 'scan' de mdadm (et permet, même si les HDz ont été intervertis, de les réordonner)
En fait c'est plutôt le superblock raid qui contient l'UUID qui indique à mdadm comment assembler ses arrays. Mais je ne suis toujours pas sûr du rapport entre superblock raid et partitioon fd...
ça confine à la masturbation intellectuelle: si tu veux *exactement* savoir comment ça marche, il suffit de charger le source du kernel et d'examiner les fichiers concernés.
Là, je crois que ça veux dire que tu ne sais pas :). Ca serait de la "masturbation" si le boot sur raid logiciel marchait toujours, mais par expérience, mettre en prod un serveur sans comprendre ce que tu fais est une erreur, et la morsure en retour est toujours cuisante ! D'ailleurs le miens est planté depuis deux jours et plus personne ne bosse ici !
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Bonjour,
Le mercredi 16 janvier 2008 à 18:59 +0100, Jean-Yves F. Barbier a
écrit :
> alors chaque disque composant l'ARRAY peut être aussi lu directement en
> ext3 (ext3 par exemple) ?
oui; c'est ce qui permet de continuer à utiliser un array en mode degraded
Et c'est donc comme ça que grub lit le noyau et l'initrd, du coup.
> 3?) la détection automatique dans le noyau des partitins
> linux-raid-autodetect intervient-elle jamais ?
si, parce que si tu interverti tes HDz, l'array continue à être correctement
détecté
Euh, non je ne crois pas... En fait le man de mdadm précise que
l'autodetection par le noyau n'intervient que si md est intégré dans le
noyau (pas dans les modules)... Donc je pense que l'autodetection "in
kernel" n'intervient pas. En plus les changelog de mdadm précisent que
ces méthode est 'deprecated' depuis au moins 2006 et que la voie à
suivre et l'utilisation de mdadm (userland) depuis l'initramfs.
> 4) dans l'initramfs, un script init-premount est appelé qui passe la main
> à udev
>
> 5) udev applique ses règles, dont :
>
> 5.1) /etc/udev/rules.d/65-persistant-storage.rules : exporte des infos en
> variables d'environnement sur les différents périphériques blocs, en
> particulier cette règle :
> ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
apparemment tu n'es pas en Sarge. Ca serait bien de le préciser...
Désolé.
> Là tout commentaire est le bienvenu.
>
> 5.2) /etc/udev/rules.d/85-mdadm.rules : lance /sbin/mdadm --assemble
> --scan --no-degraded dès qu'un device de type block dont le ID_FS_TYPE > > 'linux_raid*' est détecté par udev
> la règle est SUBSYSTEM=="block", ACTION=="add|change",
> ENV{ID_FS_TYPE}=="linux_raid*",
> RUN+="watershed /sbin/mdadm --assemble --scan --no-degraded"
>
> Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3]
> alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais
> j'ai besoin d'une petite explication...
l'option 'scan' scanne les partitions pour récupérer le membres de l'array
et leur ordre; elle n'est donc lancée qu'une fois par array
Elle lancée par udev, non ? donc si udev lance la commande plusieurs
fois, elle intervient plusieurs fois. La question est donc de savoir si
il y a un évènement par partition et si cela lance la commande à chaque
fois...
....
> Le rapport entre type de partition fd linux-raid-autodetect, superblock,
> flag raid (voir man parted) m'échappe un peu. Un superblock persitant raid
qu'est-ce que 'parted' vient faire ici? C'est un pgm qui permet de changer
la taille des partitions.
La taille mais aussi les flag, je cite :
set partition flag state
change the state of the flag on partition to state.
Flags supported are: "boot", "root", "swap", "hidden", "raid", "lvm",
"lba" and "palo". state should be either "on" or "off"
Il existe donc un flag "raid", et je ne comprends pas son rapport avec
le type de partition 'fd'.
> peut-il est écrit sur une partition de type linux, ou est-il nécessaire
> qu'elle soit de type fd ?
c'est le type 'fd' qui lance l'option 'scan' de mdadm (et permet, même si
les HDz ont été intervertis, de les réordonner)
En fait c'est plutôt le superblock raid qui contient l'UUID qui indique
à mdadm comment assembler ses arrays. Mais je ne suis toujours pas sûr
du rapport entre superblock raid et partitioon fd...
ça confine à la masturbation intellectuelle: si tu veux *exactement* savoir
comment ça marche, il suffit de charger le source du kernel et d'examiner
les fichiers concernés.
Là, je crois que ça veux dire que tu ne sais pas :). Ca serait de la
"masturbation" si le boot sur raid logiciel marchait toujours, mais par
expérience, mettre en prod un serveur sans comprendre ce que tu fais est
une erreur, et la morsure en retour est toujours cuisante ! D'ailleurs
le miens est planté depuis deux jours et plus personne ne bosse ici !
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le mercredi 16 janvier 2008 à 18:59 +0100, Jean-Yves F. Barbier a écrit :
> alors chaque disque composant l'ARRAY peut être aussi lu directement en > ext3 (ext3 par exemple) ?
oui; c'est ce qui permet de continuer à utiliser un array en mode degraded
Et c'est donc comme ça que grub lit le noyau et l'initrd, du coup.
> 3?) la détection automatique dans le noyau des partitins > linux-raid-autodetect intervient-elle jamais ?
si, parce que si tu interverti tes HDz, l'array continue à être correctement détecté
Euh, non je ne crois pas... En fait le man de mdadm précise que l'autodetection par le noyau n'intervient que si md est intégré dans le noyau (pas dans les modules)... Donc je pense que l'autodetection "in kernel" n'intervient pas. En plus les changelog de mdadm précisent que ces méthode est 'deprecated' depuis au moins 2006 et que la voie à suivre et l'utilisation de mdadm (userland) depuis l'initramfs.
> 4) dans l'initramfs, un script init-premount est appelé qui passe la main > à udev > > 5) udev applique ses règles, dont : > > 5.1) /etc/udev/rules.d/65-persistant-storage.rules : exporte des infos en > variables d'environnement sur les différents périphériques blocs, en > particulier cette règle : > ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
apparemment tu n'es pas en Sarge. Ca serait bien de le préciser...
Désolé.
> Là tout commentaire est le bienvenu. > > 5.2) /etc/udev/rules.d/85-mdadm.rules : lance /sbin/mdadm --assemble > --scan --no-degraded dès qu'un device de type block dont le ID_FS_TYPE > > 'linux_raid*' est détecté par udev > la règle est SUBSYSTEM=="block", ACTION=="add|change", > ENV{ID_FS_TYPE}=="linux_raid*", > RUN+="watershed /sbin/mdadm --assemble --scan --no-degraded" > > Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3] > alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais > j'ai besoin d'une petite explication...
l'option 'scan' scanne les partitions pour récupérer le membres de l'array et leur ordre; elle n'est donc lancée qu'une fois par array
Elle lancée par udev, non ? donc si udev lance la commande plusieurs fois, elle intervient plusieurs fois. La question est donc de savoir si il y a un évènement par partition et si cela lance la commande à chaque fois...
....
> Le rapport entre type de partition fd linux-raid-autodetect, superblock, > flag raid (voir man parted) m'échappe un peu. Un superblock persitant raid
qu'est-ce que 'parted' vient faire ici? C'est un pgm qui permet de changer la taille des partitions.
La taille mais aussi les flag, je cite :
set partition flag state change the state of the flag on partition to state. Flags supported are: "boot", "root", "swap", "hidden", "raid", "lvm", "lba" and "palo". state should be either "on" or "off"
Il existe donc un flag "raid", et je ne comprends pas son rapport avec le type de partition 'fd'.
> peut-il est écrit sur une partition de type linux, ou est-il nécessaire > qu'elle soit de type fd ?
c'est le type 'fd' qui lance l'option 'scan' de mdadm (et permet, même si les HDz ont été intervertis, de les réordonner)
En fait c'est plutôt le superblock raid qui contient l'UUID qui indique à mdadm comment assembler ses arrays. Mais je ne suis toujours pas sûr du rapport entre superblock raid et partitioon fd...
ça confine à la masturbation intellectuelle: si tu veux *exactement* savoir comment ça marche, il suffit de charger le source du kernel et d'examiner les fichiers concernés.
Là, je crois que ça veux dire que tu ne sais pas :). Ca serait de la "masturbation" si le boot sur raid logiciel marchait toujours, mais par expérience, mettre en prod un serveur sans comprendre ce que tu fais est une erreur, et la morsure en retour est toujours cuisante ! D'ailleurs le miens est planté depuis deux jours et plus personne ne bosse ici !
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
alci
Juste pour me répondre à moi-même :
Le mercredi 16 janvier 2008 à 18:59 +0100, Jean-Yves F. Barbier a écrit :
> Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3] > alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais > j'ai besoin d'une petite explication...
watershed est la fonctionnalité de udev qui évite que mdadm ne soit lancé autant de fois qu'il y a de partitions de type "linux-raid*".
Se trouve dans /lib/udev/watershed.
A priori watershed serait intégré au noyau depuis la 2.6.12. Tiré de https://wiki.edubuntu.org/UdevLvm :
"The watershed command used in the rules above is a tool to ensure that vgchange is run as many times as are necessary to process the incoming events. It works by locking a known filename, clearing a state file, and then running the command. If it cannot lock, it writes to the state file, and exits. When the command finishes, it checks the state file, and if it exists it loops and runs the command again.
This means that if two events come in hours apart, it is run twice. If one hundred come in in rapid sequence, it will be run at least twice, but usually not 100 times. "
Bon, voilà qui m'explique pourquoi ça a des chances de marcher.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Juste pour me répondre à moi-même :
Le mercredi 16 janvier 2008 à 18:59 +0100, Jean-Yves F. Barbier a
écrit :
> Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3]
> alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais
> j'ai besoin d'une petite explication...
watershed est la fonctionnalité de udev qui évite que mdadm ne soit
lancé autant de fois qu'il y a de partitions de type "linux-raid*".
Se trouve dans /lib/udev/watershed.
A priori watershed serait intégré au noyau depuis la 2.6.12.
Tiré de https://wiki.edubuntu.org/UdevLvm :
"The watershed command used in the rules above is a tool to ensure that
vgchange is run as many times as are necessary to process the incoming
events. It works by locking a known filename, clearing a state file, and
then running the command. If it cannot lock, it writes to the state
file, and exits. When the command finishes, it checks the state file,
and if it exists it loops and runs the command again.
This means that if two events come in hours apart, it is run twice. If
one hundred come in in rapid sequence, it will be run at least twice,
but usually not 100 times. "
Bon, voilà qui m'explique pourquoi ça a des chances de marcher.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le mercredi 16 janvier 2008 à 18:59 +0100, Jean-Yves F. Barbier a écrit :
> Cela veut-il dire que si j'ai 8 partitions raid1 pour composer mes md[0-3] > alors cette commande est lancée 8 fois ?!.. Là je dois me tromper, mais > j'ai besoin d'une petite explication...
watershed est la fonctionnalité de udev qui évite que mdadm ne soit lancé autant de fois qu'il y a de partitions de type "linux-raid*".
Se trouve dans /lib/udev/watershed.
A priori watershed serait intégré au noyau depuis la 2.6.12. Tiré de https://wiki.edubuntu.org/UdevLvm :
"The watershed command used in the rules above is a tool to ensure that vgchange is run as many times as are necessary to process the incoming events. It works by locking a known filename, clearing a state file, and then running the command. If it cannot lock, it writes to the state file, and exits. When the command finishes, it checks the state file, and if it exists it loops and runs the command again.
This means that if two events come in hours apart, it is run twice. If one hundred come in in rapid sequence, it will be run at least twice, but usually not 100 times. "
Bon, voilà qui m'explique pourquoi ça a des chances de marcher.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
