Salut.    
Bon je ne sais pas dans quelle catégorie mettre mon sujet là.
ça touche un peu au hardware sous Linux mais pas que.
 
Bref, j'explique en clair :
 
j'ai trois disques, dont un qui contient mon Ubuntu, les deux autres contiennent des partoches Windows & des données.
 
Je n'accède pas souvent à ces disques depuis Linux.
 
Je souhaite donc les "éteindre" complètement : pas d'écritures, têtes au repos, pas de rotation des plateaux,
afin d'économiser un peu sur leur durée de vie, en bruit, température, etc.
Et j'aimerai bien que ce soit automatique au boot de la machine (voire qu'ils ne se mettent pas du tout en route au boot, sans pour autant les débrancher physiquement).
 
Mais le truc c'est que j'aimerai bien, si tout à coup je souhaite y enregistrer ou lire quelque chose, les rallumer à la demande (commande?)
puis les ré-éteindre ensuite.
 
Et il faudrait que je sois le seul à pouvoir les "allumer", i.e. qu'aucun processus système ou autre ne puisse les remettre en route.
 
 
  Merci.

drapal, la question m'intéresse.

Salut, je ne pense pas qu'il soit possible d'empecher le démarrage d'un hdd au boot, par contre il existe une commande permettant l'arret total d'un hdd:
 
hdparm -Y /dev/sdX
 
On peut les rallumer, mais jsais plus comment, je le faisais fut une période...
Ptet la même commande, on m'avait expliqué tout ça sur... hfr
 
Bref, installe hdparm et lit la page de man ou google, tu trouveras facilement

 
C'est automatique au moindre accès.
Perso, j'utilise plutôt le timer de mise en veille (hdparm -S) pour les disques de stockage.
 
Effectivement, tu ne peux pas empêcher le hdd de s'initialiser au boot; c'est une fonction qui doit être supporté au niveau du firmware du contrôleur sur lequel le disque est branché. Ca existait, en son temps, sur certains contrôleurs SCSI mais je n'ai jamais vu ça sur du matos grand public.

Merci, ça marche plutôt bien, j'entends effectivement le disque s'arrêter complètement.
Reste plus qu'à essayer d'automatiser tout ça au boot.
J'ai pas vraiment compris le paramètre -S , et pour l'avoir essayé avec un timer de 5 sec. il ne s'est rien passé dans la minute qui a suivi.

Mais j'ai un léger problème avec hdparm -Y : je ne sais pas ci c'est suite au changement de ma CM ou si mes disques sont en AHCI (je viens de tester en IDE, c'est la même chose), mais ils redémarrent tout seul assez rapidement après être entrés en sommeil, peut-être entre 1 et 2 minutes après.

Existe-t-il un moyen de connaître exactement quel processus ou ce qui les réveille ??

Ne peut-on pas forcer l'extinction pour de bon, i.e., le réveil ne se fait que par l'utilisateur ?

Comme t'es en ntfs et que c'est un système de fichiers monté en userspace, il est possible (grosse supposition) que fuse accède aux partitions régulièrement.
 
Certaines actions provoquent le réveil des hdd dés qu'une énumération des partitions est requise (ex: mise à jour d'initramfs ou boîte de dialogues d'ouverture de fichiers sous kde).
Tant que j'en suis dans les hypothèses, le fait de démonter la partition devrait la faire disparaître aux yeux des programmes et donc, empêcher le réveil du hdd. S'il y a un moyen (aucune idée) de lire le statut "en veille" du hdd on doit pouvoir scripter le montage/démontage du hdd. Il y a p'tet même moyen qu'udev le fasse.

On va finir par y arriver, enfin j'espère, parce que je comprends pas grand chose à tout ça, mais je m'efforce.
 
Est-ce qu'on peut faire quelque chose avec ces commandes* :
 
fuser -m /dev/sdaX (X=[1,3,4,5,6]) qui renvoie, par exemple si je suis entrain d'écouter un fichier de musique situé sur /dev/sda6 avec totem :

ps auxw|grep 538 :

 
je suis tombé sur cette dernière commande ici : http://ocaoimh.ie/2008/02/13/how-t [...] e-is-busy/ en fouinant un peu le web sur ce qu'est un "système de fichier en userspace" pour me renseigner sur tout ça.
 
Dans ma tête c'est plein d'idées mais je sais pas coder avec le language interne de linux (il porte un nom en fait ?) donc c'est pas évident :
il faudrait faire en sorte de suivre (logger dans un fichier) les processus qui accèdent à toutes les partitions de /dev/sda  [1 -> 6] et de noter dans le fichier dès qu'il y en a un qui utilise une de ces partitions, peut-être qu'on peut trouver le coupable s'il y s'agit d'un processus.
 
Pour le reste, toutes mes partitions du disque sont démontées avant que je lance hdparm -Y sur ce disque.    
C'est bizarre ce "problème".
 

 
Si tes partitions sont démontées / pas montées du tout, alors c'est probablement une histoire d'irq partagé.
 
PS: pour ta culture générale, le "langage de linux" dont tu parles s'appelle généralement shell. Il y a des variantes avec des syntaxes similaires mais pas identiques et donc pas 100% compatibles entre elles (sh, bash, ash, pour les plus courantes)

Merci pour la culture. ça fait plaisir    

Comment je peux voir ces histoires d'IRQ ?

Et puis si ça peut aider quelqu'un, voilà un morceau de mon dmesg :

   -> exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6

J'ai aussi désactivé dans les préférences nautilus "media_automount". Sans succès.

Et, je ne sais pas si ça a un quelconque rapport, aussi, dans mon fichier /etc/smartd.conf : il y avait cette unique ligne de non commentée :

Mais sans la partie -n standby,q, que j'ai rajoutée par la suite. Sans succès non plus. (et je ne sais pas si la syntaxe est correcte).

drapal, pour ma culture perso.

 
Pour vérifier un éventuel irq partagé avec ton contrôleur sata, tu peux faire un  
cat /proc/interrupts
Dans l'éventualité où il partage son irq, tu peux peut-être (ça dépend du périph et de son driver) activer les MSi pour un ou plusieurs modules.
 
Ton log dmesg me semble normal pour une sortie de veille. Pour moi, le code SErr 0x0 signifie que la sortie de veille s'est déroulée sans erreur mais si tu veux être sûr, va falloir faire des recherches.

 
Le mieux c'est de vérifier qu'il n'y a pas un processus smart qui tourne en permanence (pour voir si ça vient de là).
 
Ca peut aussi venir d'un processus qui relève les températures via smart toutes les n secondes.