Bonjour,

J'ai trouvé une réponse sur Internet, mais j'ai l'espoir qu'un des spécialistes d'ici me disent que c'est possible... tout du moins comme je voudrais que ca fonctionne.

Linux 4.11.3-200.fc25.x86_64 x86_64 x86_64 x86_64
pour la configuration de base

Linux tourne sur un SSD et j'ai un DD en complement.. backup et autres usages.

Comme le DD n'est pas nécessaire en permanence, je me demandais si il existe une manipulation (clicboutonnable ca serait cool d'ailleurs) qui permette, tout en gardant le système en fonctionnement, de mettre le disque dur, soit à l'arrêt, soit en veille approfondie.. un mode qui ferait qu'il ne tourne plus en fait.. mais je me dis que si il ne tourne plus, vaudrait mieux qu'il dorme, histoire de pas chauffer...

Donc pour la question 1, auriez vous une manipulation à me proposer ?

En navigant sur Internet, je suis tombé sur le lien ci-dessous
https://doc.fedora-fr.org/wiki/Les_SSD_sous_fedora

Question 2: Pouvez vous me confirmer, ou pas, que la démarche reste toujours d'actualité ?
Comme l'article est de 2012, et que le SSD, c'est démocratisé depuis moins longtemps que le DD, je veux juste m'assurer qu'il n'y a pas eu d'update oublié..

Merci d'avance,
Cordialement,
Yoooooh
La documentation sur les SSD n'ai pas complétement à jour, notamment en ce qui concerne le trim,
Et d'après ce que j'ai lu sur d'autre forum, en particulier celui d'archlinux, cette façon de faire peut, dans quelques cas, engendrer une perte de données.

Il vaut mieux pour le trim activer le service fstrim.timer, qui fait la même chose sans ce risque : 
systemctl enable fstrim.timer
chepioq wrote:La documentation sur les SSD n'ai pas complétement à jour, notamment en ce qui concerne le trim,
Et d'après ce que j'ai lu sur d'autre forum, en particulier celui d'archlinux, cette façon de faire peut, dans quelques cas, engendrer une perte de données.

Il vaut mieux pour le trim activer le service fstrim.timer, qui fait la même chose sans ce risque : 
systemctl enable fstrim.timer
+1 !

@coyotte33 : Pourrais tu formuler ta 1ère question autrement ? Je n'ai pas compris ce que tu veux faire.
chepioq wrote:La documentation sur les SSD n'ai pas complétement à jour, notamment en ce qui concerne le trim,
Et d'après ce que j'ai lu sur d'autre forum, en particulier celui d'archlinux, cette façon de faire peut, dans quelques cas, engendrer une perte de données.

Il vaut mieux pour le trim activer le service fstrim.timer, qui fait la même chose sans ce risque : 
systemctl enable fstrim.timer
OK merci
et donc meme si 
cat /sys/block/sda/queue/scheduler
retourne toujours 
noop deadline [cfq]
après,
c'est bon quand même ?
@coyotte33 : Pourrais tu formuler ta 1ère question autrement ? Je n'ai pas compris ce que tu veux faire.

Comme le DD n'est pas nécessaire en permanence, je me demandais si il existe une manipulation (clicboutonnable ca serait cool d'ailleurs) qui permette, tout en gardant le système en fonctionnement, de mettre le disque dur, soit à l'arrêt, soit en veille approfondie.. un mode qui ferait qu'il ne tourne plus en fait.. mais je me dis que si il ne tourne plus, vaudrait mieux qu'il dorme, histoire de pas chauffer...
J'ai Fedora installer sur un SSD (total : home var .... complet)
Sur un disque dur supplementaire, j'ai, on va dire, des fichiers quelconque.
C'est à dire, que le disque dur fonctionne ou pas, ca n'a pas d'incidence sur le fonctionnement de linux, hors mis au niveau detection des disques, possiblement, ca peut gener sur le "mappage" (je suis pas sur du vocabulaire la...)
Mais un disque dur, ca tourne et donc ca fait du bruit.
Pour faire un enregistrement au micro, ca serait interessant de ne pas avoir ce bruit de fond, d'où mon interrogation:
Existe-t-il un moyen de "faire dormir" le disque dur en laissant le SSD bien réveillé, sans être contraint d'ouvrir l'ordinateur pour débrancher un cable ou deux ?? d'autant que je suis pas sur de savoir quel cable débrancher 🙂

En espérant avoir été un peu plus clair ??

Cordialement
Hello,

je ne répond pas à ta question car je n'ai aucune idée sur les possibilités de mettre en veille un DD à la demande.
Par contre, vu comment tu reformules ton besoin, je dirai que le plus simple serait de coller ton DD dans un boitier externe connecté en USB3 (pour garder un bon débit).

hth
Tu ne peux pas juste démonter la/les partitions, au sens de umount je parle.
@coyotte33 : je comprend mieux maintenant ton problème.

La question est, je pense : Est ce qu'un disque dur interne tourne, même quand il n'y a pas d'écriture et/ou lecture dessus ? Je pense que oui, mais à confirmer. Et qu'est ce qui fait le plus de bruit , la rotation du disque ou le déplacement des têtes de lecture/écriture ?

D'un autre côté, il y a toujours le bruit du ou des ventilateurs de la tour qui peut aussi gêner un enregistrement au micro !

Sinon, je suis tout à fait d'accord avec Nednet : boitier externe USB3 que l'on peut démarrer et arrêter très simplement quand on veux !

Pour le SSD : le retour de 
$ cat /sys/block/sda/queue/scheduler
doit être 
[noop] deadline cfq
C'est noop qui doit être entre crochets. cfq est pour les DD mécaniques.
https://wiki.archlinux.fr/SSD
https://wiki.archlinux.fr/Ordonnanceur_d%27E/S
Nednet wrote:Hello,

je ne répond pas à ta question car je n'ai aucune idée sur les possibilités de mettre en veille un DD à la demande.
Par contre, vu comment tu reformules ton besoin, je dirai que le plus simple serait de coller ton DD dans un boitier externe connecté en USB3 (pour garder un bon débit).

hth
Merci, mais j'ai un DD externe et .. euh.. bin non, c'est pas l'idée 🙂
le DD il est dans la tour, il sert a faire du backup, ou de l'archivage
pas lieu de le deplacer, donc pas de necessite de l'avoir en "volatile"

Cdt
Nicosss wrote:Tu ne peux pas juste démonter la/les partitions, au sens de umount je parle.
Mouai... ca semble être une idée en effet.. mais je vais la laisser murir....
Fifi wrote:@coyotte33 : je comprend mieux maintenant ton problème.

La question est, je pense : Est ce qu'un disque dur interne tourne, même quand il n'y a pas d'écriture et/ou lecture dessus ? Je pense que oui, mais à confirmer. Et qu'est ce qui fait le plus de bruit , la rotation du disque ou le déplacement des têtes de lecture/écriture ?

D'un autre côté, il y a toujours le bruit du ou des ventilateurs de la tour qui peut aussi gêner un enregistrement au micro !

Sinon, je suis tout à fait d'accord avec Nednet : boitier externe USB3 que l'on peut démarrer et arrêter très simplement quand on veux !
bon, ca va me pousser à fouiller du côté de 
mount umount
alors 🙁

merci
@coyotte33 :
J'ai modifié ma réponse #8 pour le SSD

Pour tes backup, ce n'est pas prudent de les faire sur DD interne. Il vaut mieux un DD externe que tu débranches dès que le backup est fini !

@Nicoss : Je ne sais pas si le fait de démonter ( umount ) la ou les partitions du disque empêche la rotation des plateaux ... Celle-ci ne se fait pas dès que le disque est sous tension, même partitions démontées ? Perso, je n'ai jamais fait attention.
Effectivement ça ne démontera que le système de fichiers avec umount.
Le navigateur de fichier ne propose pas une option démonter et détacher ? Sinon via l'utilitaire de gestion des Disques.

Je ne sais pas si udisk est encore utilisé sous Fedora 25 (Pas de Fedora sous la main), mais tu dois pouvoir, après avoir démonté la/les partitions, exécuter ce genre de commande sinon 
# udisks --detach /dev/sdx
Je ne sais pas si cette commande fonctionne encore avec les disques SATA, mais je ne suis pas sûr que tu puisses le réveiller sans redémarrer, ou le déconnecter/connecter. A voir dans les options de hdparm. 
# hdparm -y /dev/sdx
Fifi wrote:@coyotte33 : je comprend mieux maintenant ton problème.

La question est, je pense : Est ce qu'un disque dur interne tourne, même quand il n'y a pas d'écriture et/ou lecture dessus ? Je pense que oui, mais à confirmer. Et qu'est ce qui fait le plus de bruit , la rotation du disque ou le déplacement des têtes de lecture/écriture ?

D'un autre côté, il y a toujours le bruit du ou des ventilateurs de la tour qui peut aussi gêner un enregistrement au micro !

Sinon, je suis tout à fait d'accord avec Nednet : boitier externe USB3 que l'on peut démarrer et arrêter très simplement quand on veux !

Pour le SSD : le retour de 
$ cat /sys/block/sda/queue/scheduler
doit être 
[noop] deadline cfq
C'est noop qui doit être entre crochets. cfq est pour les DD mécaniques.
https://wiki.archlinux.fr/SSD
https://wiki.archlinux.fr/Ordonnanceur_d%27E/S
C'est bien l'objet de ma question..
c'est que apres avoir fait 
systemctl enable fstrim.timer
le resultat de (soit en su soit en sudo) 
$ cat /sys/block/sda/queue/scheduler
donne 
noop deadline [cfq]
et pas 
[noop] deadline cfq
Nicosss wrote:Effectivement ça ne démontera que le système de fichiers avec umount.
Le navigateur de fichier ne propose pas une option démonter et détacher ? Sinon via l'utilitaire de gestion des Disques.

Je ne sais pas si udisk est encore utilisé sous Fedora 25 (Pas de Fedora sous la main), mais tu dois pouvoir, après avoir démonté la/les partitions, exécuter ce genre de commande sinon 
# udisks --detach /dev/sdx
Je ne sais pas si cette commande fonctionne encore avec les disques SATA, mais je ne suis pas sûr que tu puisses le réveiller sans redémarrer, ou le déconnecter/connecter. A voir dans les options de hdparm. 
# hdparm -y /dev/sdx
udisks semble aller dans le bon sens.. mais je suis pas sur que mon anglais suive suffisamment..
ce qui me fait me poser une question de facilité...
Si je fais "libérer..." puisque c'est comme ca que ca se présente effectivement dans le gestionnaire de fichiers,
ca signifie que je fais umount
et globalement, sur le reboot, le mapping est retrouvé et mes partitions remontent toutes seules ?
coyote33 wrote:
C'est bien l'objet de ma question..
c'est que apres avoir fait 
systemctl enable fstrim.timer
le resultat de (soit en su soit en sudo) 
$ cat /sys/block/sda/queue/scheduler
donne 
noop deadline [cfq]
et pas 
[noop] deadline cfq
Tu mélanges deux choses différentes (le scheduler et le trim).
Pour avoir noop il faut que tu fasses la manœuvre indiquée avant : la partie 4.2
Il y a aussi une autre façon de le faire, mais je ne suis pas sur mon ordi en ce moment, je reviendrais en fin d'après midi
Me revoilà.
Pour avoir noop je passe par udev et je crée une règle (voir cet ancien sujet : https://forums.fedora-fr.org/viewtopic.php?id=57162 post #10 et suivant.
J'ai donc créé une règle nommée 99-ssd.rules dans /etc/udev/rule.d 
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"
Et après redémarrage j'ai bien le scheduler à noop 
~$ cat /sys/block/sda/queue/scheduler
[noop] deadline cfq
Perso, j'ai suivi le point 4.2 de la doc fedora-fr et ça fonctionne bien.
chepioq wrote:Me revoilà.
Pour avoir noop je passe par udev et je crée une règle (voir cet ancien sujet : https://forums.fedora-fr.org/viewtopic.php?id=57162 post #10 et suivant.
J'ai donc créé une règle nommée 99-ssd.rules dans /etc/udev/rule.d 
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"
Et après redémarrage j'ai bien le scheduler à noop 
~$ cat /sys/block/sda/queue/scheduler
[noop] deadline cfq
popopo de folie
a peine j'avais appuyé sur le bouton power que l'ordi était déjà lancé près à travailler 🙂
bon, oui, j'exagère... juste un petit peu..
Ok
apres redemarrage, c'est bien noop qui est en fonction
nickel
il gagne combien d'années de vie sur le coup mon ssd ??? 🙂
a la louche, une décennie ? 2 ? plus?
merci en tous cas
11 jours plus tard
Une autre solution, passer par systemd
dans /etc/systemd/system créer un service scheduler.service par exemple 
[Unit]
  Description=Check network
  Wants=network-online.target
  After=network.target network-online.target
[Service]
  Type=oneshot
  ExecStart=/etc/perso/scheduler
[Install]
  WantedBy=multi-user.target
Puis créer le script suivant et le rendre exécutable (pour moi /etc/perso/scheduler) 
#!/bin/bash
#-------  modification scheduler pour disques SSD  --------------------------------
# utilisable par le service /etc/systemd/system/scheduler.service

for disque in $(ls /dev/sd[a-z]); do
    hdparm -I $disque | grep -i TRIM         # disque SSD ?
    if [ $? -eq 0 ] ;then
        sdx=${disque:5:3}                            # récupération ID disque sdx
        scheduler=/sys/block/"$sdx"/queue/scheduler
        cat $scheduler | grep '\[cfq\]'           # Vérification mode scheduler
        if [ $? -eq 0 ]; then                        # HDD=>[cfq]  SSD=>[nop]
            echo 'noop' > $scheduler
        fi
    fi
done
exit 0
Quelle est la meilleure méthode entre systemd et udev ? Je ne le sais pas car toute les 2 fonctionnent