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 ?
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.
Ok.
(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.
Ok.
on devtmpfs ====> pour le noeud temporaire
Pas du tout. Cette partie te dit dans quel filesystem se trouve l'inode modifié : dans devtmpfs.
Ha ? soit, mais pourquoi udev écrivant dans devtmpfs réveillerait le disque ?
Nicolas George a écrit :
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.
Ok.
(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.
Ok.
on devtmpfs ====> pour le noeud temporaire
Pas du tout. Cette partie te dit dans quel filesystem se trouve l'inode
modifié : dans devtmpfs.
Ha ? soit, mais pourquoi udev écrivant dans devtmpfs réveillerait le
disque ?
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.
Ok.
(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.
Ok.
on devtmpfs ====> pour le noeud temporaire
Pas du tout. Cette partie te dit dans quel filesystem se trouve l'inode modifié : dans devtmpfs.
Ha ? soit, mais pourquoi udev écrivant dans devtmpfs réveillerait le disque ?
Nicolas George
GuiGui wrote in message <4bfe85e0$0$9754$:
Ha ? soit, mais pourquoi udev écrivant dans devtmpfs réveillerait le disque ?
Il ne le fait pas.
GuiGui wrote in message <4bfe85e0$0$9754$426a74cc@news.free.fr>:
Ha ? soit, mais pourquoi udev écrivant dans devtmpfs réveillerait le
disque ?
Ha ? soit, mais pourquoi udev écrivant dans devtmpfs réveillerait le disque ?
Il ne le fait pas.
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.
Bon, voila à présent plus de 10 heures que le disque ne s'est pas réveillé, dont presque 5 heures alors que le service smartd s'exécute. Je suis donc quasiment certain que ce n'est pas ce dernier qui cause le réveil du disque mais quelque chose qui intervient au cours d'une session xfce. (Sans qu'un utilisateur utilise consciemment un programme quelconque.)
Demain, j'essaierai de dresser la liste des processus qui ne s'exécutent que dans une session xfce. Dois-je citer aussi les services actifs ? Est-ce une bonne idée ? Quelqu'un en aura sûrement une meilleure ?
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.
Bon, voila à présent plus de 10 heures que le disque ne s'est pas réveillé,
dont presque 5 heures alors que le service smartd s'exécute. Je suis donc
quasiment certain que ce n'est pas ce dernier qui cause le réveil du disque
mais quelque chose qui intervient au cours d'une session xfce. (Sans qu'un
utilisateur utilise consciemment un programme quelconque.)
Demain, j'essaierai de dresser la liste des processus qui ne s'exécutent que
dans une session xfce. Dois-je citer aussi les services actifs ? Est-ce une
bonne idée ? Quelqu'un en aura sûrement une meilleure ?
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.
Bon, voila à présent plus de 10 heures que le disque ne s'est pas réveillé, dont presque 5 heures alors que le service smartd s'exécute. Je suis donc quasiment certain que ce n'est pas ce dernier qui cause le réveil du disque mais quelque chose qui intervient au cours d'une session xfce. (Sans qu'un utilisateur utilise consciemment un programme quelconque.)
Demain, j'essaierai de dresser la liste des processus qui ne s'exécutent que dans une session xfce. Dois-je citer aussi les services actifs ? Est-ce une bonne idée ? Quelqu'un en aura sûrement une meilleure ?
debug this fifo
geo cherchetout wrote:
réveil du disque mais quelque chose qui intervient au cours d'une session xfce.
un automounter quelconque ?
geo cherchetout wrote:
réveil du disque mais quelque chose qui intervient au cours d'une
session xfce.
Après maints longs essais, je pense avoir trouvé les principales mesures permettant de le maintenir au repos après un arrêt par hdparm -Y :
- Ne pas le faire figurer dans /etc/smartd.conf. Après tout, ce disque étant voué à un autre OS, ce dernier pourra bien se charger de le monitorer. - Que la partition qu'il contient ne soit pas montée et que l'utilisateur ne cherche pas à voir le contenu de /media, point de montage de cette partition. - Ne pas l'interroger avec smartctl.
Merci à ceux qui m'ont répondu.
Après maints longs essais, je pense avoir trouvé les principales mesures
permettant de le maintenir au repos après un arrêt par hdparm -Y :
- Ne pas le faire figurer dans /etc/smartd.conf. Après tout, ce disque étant
voué à un autre OS, ce dernier pourra bien se charger de le monitorer.
- Que la partition qu'il contient ne soit pas montée et que l'utilisateur ne
cherche pas à voir le contenu de /media, point de montage de cette partition.
- Ne pas l'interroger avec smartctl.
Après maints longs essais, je pense avoir trouvé les principales mesures permettant de le maintenir au repos après un arrêt par hdparm -Y :
- Ne pas le faire figurer dans /etc/smartd.conf. Après tout, ce disque étant voué à un autre OS, ce dernier pourra bien se charger de le monitorer. - Que la partition qu'il contient ne soit pas montée et que l'utilisateur ne cherche pas à voir le contenu de /media, point de montage de cette partition. - Ne pas l'interroger avec smartctl.
Merci à ceux qui m'ont répondu.
Lucas Levrel
Le 29 mai 2010, geo cherchetout a écrit :
Après maints longs essais, je pense avoir trouvé les principales mesures permettant de le maintenir au repos après un arrêt par hdparm -Y :
- Ne pas le faire figurer dans /etc/smartd.conf. Après tout, ce disque étant voué à un autre OS, ce dernier pourra bien se charger de le monitorer. - Que la partition qu'il contient ne soit pas montée et que l'utilisateur ne cherche pas à voir le contenu de /media, point de montage de cette partition. - Ne pas l'interroger avec smartctl.
Au final, quoi de neuf depuis ton message sur les processus lancés par Xfce ?
-- LL
Le 29 mai 2010, geo cherchetout a écrit :
Après maints longs essais, je pense avoir trouvé les principales mesures
permettant de le maintenir au repos après un arrêt par hdparm -Y :
- Ne pas le faire figurer dans /etc/smartd.conf. Après tout, ce disque étant
voué à un autre OS, ce dernier pourra bien se charger de le monitorer.
- Que la partition qu'il contient ne soit pas montée et que l'utilisateur ne
cherche pas à voir le contenu de /media, point de montage de cette partition.
- Ne pas l'interroger avec smartctl.
Au final, quoi de neuf depuis ton message sur les processus lancés par
Xfce ?
Après maints longs essais, je pense avoir trouvé les principales mesures permettant de le maintenir au repos après un arrêt par hdparm -Y :
- Ne pas le faire figurer dans /etc/smartd.conf. Après tout, ce disque étant voué à un autre OS, ce dernier pourra bien se charger de le monitorer. - Que la partition qu'il contient ne soit pas montée et que l'utilisateur ne cherche pas à voir le contenu de /media, point de montage de cette partition. - Ne pas l'interroger avec smartctl.
Au final, quoi de neuf depuis ton message sur les processus lancés par Xfce ?
-- LL
geo cherchetout
Le 31/05/2010 12:36, *Lucas Levrel* a écrit fort à propos :
Au final, quoi de neuf depuis ton message sur les processus lancés par Xfce ?
Rien de neuf. Les essais prolongés évoqués ci-dessus furent effectués avec une session xfce ouverte mais très peu d'activité de l'utilisateur. (La plupart du temps seul Terminal était exécuté et aucune autre application.)
Le 31/05/2010 12:36, *Lucas Levrel* a écrit fort à propos :
Au final, quoi de neuf depuis ton message sur les processus lancés par
Xfce ?
Rien de neuf. Les essais prolongés évoqués ci-dessus furent effectués avec
une session xfce ouverte mais très peu d'activité de l'utilisateur. (La
plupart du temps seul Terminal était exécuté et aucune autre application.)
Le 31/05/2010 12:36, *Lucas Levrel* a écrit fort à propos :
Au final, quoi de neuf depuis ton message sur les processus lancés par Xfce ?
Rien de neuf. Les essais prolongés évoqués ci-dessus furent effectués avec une session xfce ouverte mais très peu d'activité de l'utilisateur. (La plupart du temps seul Terminal était exécuté et aucune autre application.)
