Hello Fréderic,
Le 14/07/2016 à 16:56, Frédéric a écrit :
> Le jeudi 14 juillet 2016, Olivier a écrit :
>
>> Pour moi, ce ne sont pas des erreurs. C'est juste une
>> information qui te dit que le mécanisme de cache **interne** du disque
>> est désactivé pour les écritures. Ce qui veut dire que lorsque l'OS
>> enverra une écriture de données sur le disque, celui-ci ne rendra la
>> main que lorsqu'il aura terminé le boulot.
>>
>> C'est une perte de perf par rapport aux capacités réels du disque
>> (désactivation, pour les écritures, des xx Mo de cache interne au
>> disque).
>>
>> Mais pour un périphérique amovible, c'est la garantie que les
>> données sont bien écrites. Il y a certes encore le mécanisme de cache de
>> l'OS, mais cela, ce n'est pas la responsabilité du disque.
>>
>> Je pense que c'est un choix du constructeur de la station, que
>> d'avoir désactivé le cache en écriture, et cela me paraît normal. Dans
>> le cas contraire, il devrait y avoir un batterie de secours dans la
>> station, afin de supporter le cache en écriture. C'est le cas par
>> exemple pour certains contrôleurs RAID.
>
> Pas sûr de piger : tu parles du cache du disque... C'est donc indépendant
> du contrôleur sata, non ?
Dans le disque dur, il y a un morceau de mémoire vive, géré par le
disque dur lui-même, et qui sert de cache. Actuellement, c'est souvent
64Mo, mais ce n'est pas une obligation.
Cette mémoire peut être activée, ou non, par le contrôleur disque
(SATA), mais l'OS peut aussi avoir la main dessus (au moins en partie,
via hdparm).
Exemple chez moi sur un "dmesg |grep -i cache" :
# dmesg |grep -i cache
[ 2.320896] sd 3:0:0:0: [sdb] **Write cache: enabled**, read cache:
enabled, doesn't support DPO or FUA
[ 2.320903] sd 2:0:0:0: [sda] **Write cache: enabled**, read cache:
enabled, doesn't support DPO or FUA
Sur mes deux disques SATA, j'ai le cache des disques activés en
écriture ET en lecture.
Dans le cas de ton boîtier USB/SATA, lorsque le kernel Linux lui
demande ce que le disque peut faire, le contrôleur SATA lui répond "le
disque n'ai pas de cache disque". Il ment donc sur les capacités réelles
du disques, mais c'est pour des raisons de sécurité des données.
> En tout cas, l'autre boîtier du même style ne montre pas ça : le cache est
> donc activé.
Oui. Autre constructeurs, autre méthodes.
Remarque en ce qui concerne les NAS. Certains NAS réseaux domestiques
que l'on trouve sur le marché peuvent mettre les disques en standby,
lorsque qu'il n'y a pas d'activité. Mais que ce passe t'il si une
machine du réseau envoie régulièrement des broadcast (SMB par exemple,
mais aussi uPNP, etc ...), afin de savoir qui est présent ?
Simple :
- Au mieux, cela empêche les disque de passer en mode standby, car ils
sont sollicités souvent => Augmentation du uptime, et consomation électrique
- Au pire le disque passe son temps à se mettre en standby puis se
ré-allume, et là, il n'y a pas mieux pour le détruire ...
- Il est possible cependant que certains NAS sont assez "intelligents"
pour garder des infos dans le cache (du NAS), comme par exemple la
taille du disque, et ainsi ne rallume pas le disque à la moindre
sollicitation.
>> Je pense que le constructeur de la station (plutôt du chipset
>> usb <-> sata) n'a pas implémenté toutes les spécificité du protocole
>> SATA.
>
> Ok, mais le spindown, qui le gère ? Le disque, ou le contrôleur sata ?
Le disque est "stupide" : il ne fait que répondre aux sollicitations
qu'il reçoit du contrôleur SATA (c'est la seule chose qu'il voit
d'ailleurs).
Le contrôleur SATA peut, lui, envoyer directement les requêtes de l'OS
vers le disque dur. Mais il peut aussi en ignorer certaines, et mentir
sur ce que le disque peut faire. On va dire qu'il a un rôle de "censure".
> Pourquoi cela fonctionne-t-il lorsque je l'active (à travers ce boîtier),
> mais plus une fois le disque éteint/rallumé ? Alors qu'il s'éteint bien si
> je le met dans l'autre...
Il semble qu'il y ait 2 problèmes différents:
<extrait>
J'ai ce boîtier :
http://www.ldlc.com/fiche/PB00184700.html
dans lequel les disques ne s'arrêtent jamais ! Alors qu'ils fonctionnent
bien dans un autre boîtier du même genre.
</extrait>
Il est possible que le contrôleur, de lui-même, envoie en permanence
des sollicitations au disque, l'empêchant ainsi de se mettre en pause.
Ou alors, il est possible que l'OS envoie des sorte de "keep alive USB"
au contrôleur, et que celui-ci prennent cela pour des sollicitation du
disque, et donc envoient des commandes au disque. L'empéchant donc de
passer en standby.
Alors que l'autre contrôleur comprend que ce n'est que des informations
destinée à vérifier la validité la communication USB, et donc n'envoie
pas de message au disque, ce qui permet à celui-ci de s'arrêter.
<extrait>
Le auto spindown fonctionne immédiatement après la commande hdparm -S,
mais dès qu'on débranche le disque pour le déplacer, ça ne marche plus.
</extrait>
Il est possible que le contrôleur USB/SATA prennent aussi cette
commande pour lui, ce qui veut dire qu'il s'arrête lui aussi. Par
exemple en considérant que tu vas arrêter l'ordinateur, et donc que tu
n'as plus besoin de ses services ?
Ou plus simple encore:
- lorsque tu connectes le contrôleur, il s'initialise et envoie la
puissance au disque, qui peut s'initialiser lui aussi
- mais après la commande "hdparm -S", le contrôleur passe lui aussi en
mode "sommeil", et devient alors incapable de détecter l'insersion d'un
nouveau disque.
Il est donc possible que ce soit un bug du contrôleur.
Workaround possible : D'après une photo, il y a un bouton on/off en
face arrière, cela fait quoi si tu fais un on/off AVANT d'insérer le
disque de nouveau ?
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
