Le vieil ordinateur que je prépare pour mon neveu possède deux disques durs
/dev/sda et /dev/sdb. Sur /dev/sda est installé Windows XP et Grub siège
dans son MBR. Sur /dev/sdb se trouvent les partitions consacrées à mandriva
2010.
Quand on démarre Mandriva, j'aimerais que le disque Windows soit arrêté le
plus tôt possible et reste à l'arrêt aussi longtemps qu'on n'a pas besoin
d'y accéder.
Si je fais hdparm -y /dev/sda ou hdparm -Y /dev/sda, le disque cesse bien de
tourner mais il ne peut s'empêcher de redémarrer au bout d'un certain temps,
même si son unique partition est préalablement démontée.
Avez vous idée d'une option dans fstab ou de tout autre procédé soft
permettant d'obtenir un arrêt durable ?
Pour connaitre les processus qui accède aux disques : echo 1 > /proc/sys/vm/block_dump et dans dmesg, on peut alors voir : atop(720): dirtied inode 468512 (atop.log) on sda1
Mais si la partition est démontée, je ne sais pas si tu verras qqch
Ça y est, on dirait que ça mord, le disque vient de redémarrer malgré moi après quelques heures de repos à l'issue de ma dernière expérience, sa partition n'a pas cessé d'être montée et voici ce que dit dmesg :
udevd(144): dirtied inode 194657 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs udevd(826): dirtied inode 202970 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs
Bon, ben voilà : c'est udev qui te réveille ton disque. Mais là, je ne vois pas pourquoi.
syslog me donne l'heure des messages :
# cat /var/log/syslog | grep 194657 May 26 20:29:32 localhost klogd: udevd(144): dirtied inode 194657 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs
# cat /var/log/syslog | grep 202970 May 26 20:29:32 localhost klogd: udevd(826): dirtied inode 202970 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs
et voici ce que je trouve dans /var/log/messages :
May 26 20:29:32 localhost smartd[958]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 40 to 41 May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, is back in ACTIVE or IDLE mode, resuming checks (6 checks skipped)
Ouaip, smartd a vu que le disque s'est réveillé et en a profité pour le tester.
May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, SMART Usage Attribute: 1 Raw_Read_Error_Rate changed from 54 to 55 May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 35 to 36 May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 64 to 62
Et enfin pour décrire les conditions de l'expérience voila ce que j'avais mis dans /etc/smartd.conf
/dev/sdb -a -o on -S on -s L/../../6/12 /dev/sda -n idle,q -o off -S off -s L/../../6/12
Ça correspond au comportement observé : smartd ne fait rien jusqu'à ce qu'un autre process réveille le disque.
Les soupçons convergent vers smartd mais j'apprécierai une explication. Est-il utile de l'avouer, le man de smartd.conf ne m'éclaire pas complètement, probablement parce que je ne connais pas grand-chose à SMART...
Je crois que tu as fait ce qu'il faut sur smart. Maitenant il va falloir s'attaquer à udev :-(
geo cherchetout a écrit :
Le 25/05/2010 17:35, *david.hautbois@gmail.com* a écrit fort à propos :
Pour connaitre les processus qui accède aux disques :
echo 1 > /proc/sys/vm/block_dump
et dans dmesg, on peut alors voir :
atop(720): dirtied inode 468512 (atop.log) on sda1
Mais si la partition est démontée, je ne sais pas si tu verras qqch
Ça y est, on dirait que ça mord, le disque vient de redémarrer malgré
moi après quelques heures de repos à l'issue de ma dernière expérience,
sa partition n'a pas cessé d'être montée et voici ce que dit dmesg :
udevd(144): dirtied inode 194657
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda)
on devtmpfs
udevd(826): dirtied inode 202970
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda)
on devtmpfs
Bon, ben voilà : c'est udev qui te réveille ton disque. Mais là, je ne
vois pas pourquoi.
syslog me donne l'heure des messages :
# cat /var/log/syslog | grep 194657
May 26 20:29:32 localhost klogd: udevd(144): dirtied inode 194657
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda)
on devtmpfs
# cat /var/log/syslog | grep 202970
May 26 20:29:32 localhost klogd: udevd(826): dirtied inode 202970
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda)
on devtmpfs
et voici ce que je trouve dans /var/log/messages :
May 26 20:29:32 localhost smartd[958]: Device: /dev/sdb, SMART Usage
Attribute: 194 Temperature_Celsius changed from 40 to 41
May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, is back in
ACTIVE or IDLE mode, resuming checks (6 checks skipped)
Ouaip, smartd a vu que le disque s'est réveillé et en a profité pour le
tester.
May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, SMART Usage
Attribute: 1 Raw_Read_Error_Rate changed from 54 to 55
May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, SMART Usage
Attribute: 194 Temperature_Celsius changed from 35 to 36
May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, SMART Usage
Attribute: 195 Hardware_ECC_Recovered changed from 64 to 62
Et enfin pour décrire les conditions de l'expérience voila ce que
j'avais mis dans /etc/smartd.conf
/dev/sdb -a -o on -S on -s L/../../6/12
/dev/sda -n idle,q -o off -S off -s L/../../6/12
Ça correspond au comportement observé : smartd ne fait rien jusqu'à ce
qu'un autre process réveille le disque.
Les soupçons convergent vers smartd mais j'apprécierai une explication.
Est-il utile de l'avouer, le man de smartd.conf ne m'éclaire pas
complètement, probablement parce que je ne connais pas grand-chose à
SMART...
Je crois que tu as fait ce qu'il faut sur smart. Maitenant il va falloir
s'attaquer à udev :-(
Pour connaitre les processus qui accède aux disques : echo 1 > /proc/sys/vm/block_dump et dans dmesg, on peut alors voir : atop(720): dirtied inode 468512 (atop.log) on sda1
Mais si la partition est démontée, je ne sais pas si tu verras qqch
Ça y est, on dirait que ça mord, le disque vient de redémarrer malgré moi après quelques heures de repos à l'issue de ma dernière expérience, sa partition n'a pas cessé d'être montée et voici ce que dit dmesg :
udevd(144): dirtied inode 194657 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs udevd(826): dirtied inode 202970 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs
Bon, ben voilà : c'est udev qui te réveille ton disque. Mais là, je ne vois pas pourquoi.
syslog me donne l'heure des messages :
# cat /var/log/syslog | grep 194657 May 26 20:29:32 localhost klogd: udevd(144): dirtied inode 194657 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs
# cat /var/log/syslog | grep 202970 May 26 20:29:32 localhost klogd: udevd(826): dirtied inode 202970 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs
et voici ce que je trouve dans /var/log/messages :
May 26 20:29:32 localhost smartd[958]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 40 to 41 May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, is back in ACTIVE or IDLE mode, resuming checks (6 checks skipped)
Ouaip, smartd a vu que le disque s'est réveillé et en a profité pour le tester.
May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, SMART Usage Attribute: 1 Raw_Read_Error_Rate changed from 54 to 55 May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 35 to 36 May 26 20:29:32 localhost smartd[958]: Device: /dev/sda, SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 64 to 62
Et enfin pour décrire les conditions de l'expérience voila ce que j'avais mis dans /etc/smartd.conf
/dev/sdb -a -o on -S on -s L/../../6/12 /dev/sda -n idle,q -o off -S off -s L/../../6/12
Ça correspond au comportement observé : smartd ne fait rien jusqu'à ce qu'un autre process réveille le disque.
Les soupçons convergent vers smartd mais j'apprécierai une explication. Est-il utile de l'avouer, le man de smartd.conf ne m'éclaire pas complètement, probablement parce que je ne connais pas grand-chose à SMART...
Je crois que tu as fait ce qu'il faut sur smart. Maitenant il va falloir s'attaquer à udev :-(
GuiGui
GuiGui a écrit :
geo cherchetout a écrit :
Le 25/05/2010 17:35, ** a écrit fort à propos :
Pour connaitre les processus qui accède aux disques : echo 1 > /proc/sys/vm/block_dump et dans dmesg, on peut alors voir : atop(720): dirtied inode 468512 (atop.log) on sda1
Mais si la partition est démontée, je ne sais pas si tu verras qqch
Ça y est, on dirait que ça mord, le disque vient de redémarrer malgré moi après quelques heures de repos à l'issue de ma dernière expérience, sa partition n'a pas cessé d'être montée et voici ce que dit dmesg :
udevd(144): dirtied inode 194657 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs udevd(826): dirtied inode 202970 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs
Bon, ben voilà : c'est udev qui te réveille ton disque. Mais là, je ne vois pas pourquoi.
Le 25/05/2010 17:35, *david.hautbois@gmail.com* a écrit fort à propos :
Pour connaitre les processus qui accède aux disques :
echo 1 > /proc/sys/vm/block_dump
et dans dmesg, on peut alors voir :
atop(720): dirtied inode 468512 (atop.log) on sda1
Mais si la partition est démontée, je ne sais pas si tu verras qqch
Ça y est, on dirait que ça mord, le disque vient de redémarrer malgré
moi après quelques heures de repos à l'issue de ma dernière
expérience, sa partition n'a pas cessé d'être montée et voici ce que
dit dmesg :
udevd(144): dirtied inode 194657
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda)
on devtmpfs
udevd(826): dirtied inode 202970
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda)
on devtmpfs
Bon, ben voilà : c'est udev qui te réveille ton disque. Mais là, je ne
vois pas pourquoi.
Pour connaitre les processus qui accède aux disques : echo 1 > /proc/sys/vm/block_dump et dans dmesg, on peut alors voir : atop(720): dirtied inode 468512 (atop.log) on sda1
Mais si la partition est démontée, je ne sais pas si tu verras qqch
Ça y est, on dirait que ça mord, le disque vient de redémarrer malgré moi après quelques heures de repos à l'issue de ma dernière expérience, sa partition n'a pas cessé d'être montée et voici ce que dit dmesg :
udevd(144): dirtied inode 194657 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs udevd(826): dirtied inode 202970 (x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) on devtmpfs
Bon, ben voilà : c'est udev qui te réveille ton disque. Mais là, je ne vois pas pourquoi.
Non, mais x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda en est un.
Oui, mais le message que tu as cité ne dit pas qu'il a été modifié.
Lucas Levrel
Le 27 mai 2010, geo cherchetout a écrit :
Merci, je veux bien poursuivre les investigations si on me dirige et si je comprends les actions proposées.
Ça ne serait pas un processus d'indexation qui démarre à heure ou période fixe ? Tu n'as pas précisé ton environnement... Tu peux essayer de démarrer sans X, donc sans bureau (mets "3" comme option à l'invite de GRUB).
-- LL
Le 27 mai 2010, geo cherchetout a écrit :
Merci, je veux bien poursuivre les investigations si on me dirige et si je
comprends les actions proposées.
Ça ne serait pas un processus d'indexation qui démarre à heure ou période
fixe ? Tu n'as pas précisé ton environnement... Tu peux essayer de
démarrer sans X, donc sans bureau (mets "3" comme option à l'invite de
GRUB).
Merci, je veux bien poursuivre les investigations si on me dirige et si je comprends les actions proposées.
Ça ne serait pas un processus d'indexation qui démarre à heure ou période fixe ? Tu n'as pas précisé ton environnement... Tu peux essayer de démarrer sans X, donc sans bureau (mets "3" comme option à l'invite de GRUB).
-- LL
geo cherchetout
Le 27/05/2010 14:45, *Lucas Levrel* a écrit fort à propos :
Ça ne serait pas un processus d'indexation qui démarre à heure ou période fixe ? Tu n'as pas précisé ton environnement... Tu peux essayer de démarrer sans X, donc sans bureau (mets "3" comme option à l'invite de GRUB).
Ne sachant pas obtenir l'invite de GRUB, je viens, sans redémarrer, de déconnecter l'unique utilisateur qui était connecté. Son environnement de bureau habituel est xfce. J'avais carrément mis le service smartd à l'arrêt vers 13h40 après un réveil du disque.
[ ~]# date; hdparm -C /dev/sda jeu. mai 27 15:24:50 CEST 2010
/dev/sda: drive state is: standby
Le 27/05/2010 14:45, *Lucas Levrel* a écrit fort à propos :
Ça ne serait pas un processus d'indexation qui démarre à heure ou période
fixe ? Tu n'as pas précisé ton environnement... Tu peux essayer de
démarrer sans X, donc sans bureau (mets "3" comme option à l'invite de
GRUB).
Ne sachant pas obtenir l'invite de GRUB, je viens, sans redémarrer, de
déconnecter l'unique utilisateur qui était connecté. Son environnement de
bureau habituel est xfce. J'avais carrément mis le service smartd à l'arrêt
vers 13h40 après un réveil du disque.
[root@localhost ~]# date; hdparm -C /dev/sda
jeu. mai 27 15:24:50 CEST 2010
Le 27/05/2010 14:45, *Lucas Levrel* a écrit fort à propos :
Ça ne serait pas un processus d'indexation qui démarre à heure ou période fixe ? Tu n'as pas précisé ton environnement... Tu peux essayer de démarrer sans X, donc sans bureau (mets "3" comme option à l'invite de GRUB).
Ne sachant pas obtenir l'invite de GRUB, je viens, sans redémarrer, de déconnecter l'unique utilisateur qui était connecté. Son environnement de bureau habituel est xfce. J'avais carrément mis le service smartd à l'arrêt vers 13h40 après un réveil du disque.
[ ~]# date; hdparm -C /dev/sda jeu. mai 27 15:24:50 CEST 2010
/dev/sda: drive state is: standby
GuiGui
Nicolas George a écrit :
GuiGui wrote in message <4bfe624a$0$7194$:
Non, mais x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda en est un.
Oui, mais le message que tu as cité ne dit pas qu'il a été modifié.
Si je lis bien ce à quoi j'ai répondu :
udevd(144): dirtied inode 194657 ====> udev a modifié un disque
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) =====> c'est le block device sda (justement celui qui a posé un pb)
on devtmpfs ====> pour le noeud temporaire
Ce que je ne comprend pas c'est que devtmpfs n'est, il me semble, pas sensé être utilisé après le boot (i.e. après que devtmpfs soit muté sur /dev). Ou alors il s'agirait d'un bug du kernel ?
Mais bon, je ne suis pas un spécialiste du kernel non plus, donc si tu peux décortiquer la raison qui fait utiliser devtmpfs je suis preneur.
Nicolas George a écrit :
GuiGui wrote in message <4bfe624a$0$7194$426a74cc@news.free.fr>:
Non, mais
x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda
en est un.
Oui, mais le message que tu as cité ne dit pas qu'il a été modifié.
Si je lis bien ce à quoi j'ai répondu :
udevd(144): dirtied inode 194657 ====> udev a modifié un disque
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda)
=====> c'est le block device sda (justement celui qui a posé un pb)
on devtmpfs ====> pour le noeud temporaire
Ce que je ne comprend pas c'est que devtmpfs n'est, il me semble, pas
sensé être utilisé après le boot (i.e. après que devtmpfs soit muté sur
/dev). Ou alors il s'agirait d'un bug du kernel ?
Mais bon, je ne suis pas un spécialiste du kernel non plus, donc si tu
peux décortiquer la raison qui fait utiliser devtmpfs je suis preneur.
Non, mais x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda en est un.
Oui, mais le message que tu as cité ne dit pas qu'il a été modifié.
Si je lis bien ce à quoi j'ai répondu :
udevd(144): dirtied inode 194657 ====> udev a modifié un disque
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) =====> c'est le block device sda (justement celui qui a posé un pb)
on devtmpfs ====> pour le noeud temporaire
Ce que je ne comprend pas c'est que devtmpfs n'est, il me semble, pas sensé être utilisé après le boot (i.e. après que devtmpfs soit muté sur /dev). Ou alors il s'agirait d'un bug du kernel ?
Mais bon, je ne suis pas un spécialiste du kernel non plus, donc si tu peux décortiquer la raison qui fait utiliser devtmpfs je suis preneur.
Nicolas George
GuiGui wrote in message <4bfe797b$0$6276$:
Si je lis bien ce à quoi j'ai répondu :
udevd(144): dirtied inode 194657 ====> udev a modifié un disque
Jusque là, oui, à peu près. Plus exactement, il a modifié un inode, c'est à dire le coeur d'un fichier dans un filesystem.
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) =====> c'est le block device sda (justement celui qui a posé un pb)
Non. Le message te dit que l'inode modifié est celui qui s'appelle, dans le filesystem concerné, « x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda ». Il se trouve que ce fichier évoque un disque dur, mais ça n'en est pas un. C'est un fichier régulier dont udev se sert pour garder la trace des entrées qu'il a créées.
on devtmpfs ====> pour le noeud temporaire
Pas du tout. Cette partie te dit dans quel filesystem se trouve l'inode modifié : dans devtmpfs.
On pourrait modifier la phrase pour la rendre plus lisible :
touch(18173): dirtied inode 830378 (passwd) on sda1
(après un sudo touch /etc/passwd).
Ce que je ne comprend pas c'est que devtmpfs n'est, il me semble, pas sensé être utilisé après le boot (i.e. après que devtmpfs soit muté sur /dev).
Là, tu t'embrouilles complètement. Tu confonds initrd (un filesystem compressé, chargé en RAM par le bootloader et qui est complètement oublié quand le noyau a fini de booter) et devtmpfs (un tmpfs monté par udev sur /dev dans lequel il crée les entrées pour les devices) ; le nom devtmpfs est purement formel.
GuiGui wrote in message <4bfe797b$0$6276$426a74cc@news.free.fr>:
Si je lis bien ce à quoi j'ai répondu :
udevd(144): dirtied inode 194657 ====> udev a modifié un disque
Jusque là, oui, à peu près. Plus exactement, il a modifié un inode, c'est à
dire le coeur d'un fichier dans un filesystem.
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda)
=====> c'est le block device sda (justement celui qui a posé un pb)
Non. Le message te dit que l'inode modifié est celui qui s'appelle, dans le
filesystem concerné,
« x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda ». Il
se trouve que ce fichier évoque un disque dur, mais ça n'en est pas un.
C'est un fichier régulier dont udev se sert pour garder la trace des entrées
qu'il a créées.
on devtmpfs ====> pour le noeud temporaire
Pas du tout. Cette partie te dit dans quel filesystem se trouve l'inode
modifié : dans devtmpfs.
On pourrait modifier la phrase pour la rendre plus lisible :
touch(18173): dirtied inode 830378 (passwd) on sda1
(après un sudo touch /etc/passwd).
Ce que je ne comprend pas c'est que devtmpfs n'est, il me semble, pas
sensé être utilisé après le boot (i.e. après que devtmpfs soit muté sur
/dev).
Là, tu t'embrouilles complètement. Tu confonds initrd (un filesystem
compressé, chargé en RAM par le bootloader et qui est complètement oublié
quand le noyau a fini de booter) et devtmpfs (un tmpfs monté par udev sur
/dev dans lequel il crée les entrées pour les devices) ; le nom devtmpfs est
purement formel.
udevd(144): dirtied inode 194657 ====> udev a modifié un disque
Jusque là, oui, à peu près. Plus exactement, il a modifié un inode, c'est à dire le coeur d'un fichier dans un filesystem.
(x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda) =====> c'est le block device sda (justement celui qui a posé un pb)
Non. Le message te dit que l'inode modifié est celui qui s'appelle, dans le filesystem concerné, « x2fdevicesx2fpci0000:00x2f0000:00:1f.1x2fhost0x2ftarget0:0:0x2f0:0:0:0x2fblockx2fsda ». Il se trouve que ce fichier évoque un disque dur, mais ça n'en est pas un. C'est un fichier régulier dont udev se sert pour garder la trace des entrées qu'il a créées.
on devtmpfs ====> pour le noeud temporaire
Pas du tout. Cette partie te dit dans quel filesystem se trouve l'inode modifié : dans devtmpfs.
On pourrait modifier la phrase pour la rendre plus lisible :
touch(18173): dirtied inode 830378 (passwd) on sda1
(après un sudo touch /etc/passwd).
Ce que je ne comprend pas c'est que devtmpfs n'est, il me semble, pas sensé être utilisé après le boot (i.e. après que devtmpfs soit muté sur /dev).
Là, tu t'embrouilles complètement. Tu confonds initrd (un filesystem compressé, chargé en RAM par le bootloader et qui est complètement oublié quand le noyau a fini de booter) et devtmpfs (un tmpfs monté par udev sur /dev dans lequel il crée les entrées pour les devices) ; le nom devtmpfs est purement formel.
