On Thu, 7 Jun 2001, Marc Mongenet wrote:
> j'aimerais savoir comment je peux d�terminer quels sont mes p�riph�riques
> SCSI qui supportent le "tagged command queing". Suffit-il d'essayer en
Cette capacit� est un bit de l'INQUIRY des disques SCSI. Cela ne t'aide
pas, mais c'est juste pour faire comprendre que la `capacit� � le faire'
est indiqu�e � l'ordinateur quel que soit le setting du BIOS concern�.
De plus, la tentative de n�gociation (qui sera refus�e par le disque s'il
ne la supporte pas) n'est effectu�e, en g�n�ral, que si elle est activ�e
par le BIOS (m�me sous Linux, la plupart des pilotes bas-niveau lisent la
config sur la carte; p.ex. sym53c8xx et aic7xxx).
Et il faut savoir qu'il y a �galement des options de compilation des
pilotes pour limiter voir supprimer ces tentatives. Lire les Configure et
README (drivers/scsi/README.ncr53c8xx p.ex.).
Enfin, il existe diff�rents types de command queuing: ORDERED, SIMPLE,
etc, qui peuvent �tre rejet�s individuellement par les cibles SCSI
(disques, etc).
Donc, pour r�pondre � ta question, pour savoir, m�me si l'option BIOS
n'est pas activ�e ou que le pilote n'est pas configur�/compil� avec cette
option tu peux faire scsiinfo (programme en tcl/tk en surcouche � un
programme en C) qui va t'indiquer toutes les options possibles pour un
p�riph�rique donn�. Avec cet outil tu peux aussi changer les param�tres
de caching, v�rifier le nombre de segments, et changer les param�tres de
correction d'erreur (nombre de relectures, remplacement de blocs
automatique ou non, avec communication des erreurs corrig�es ou non). Tout
un monde � exp�rimenter :)
Debian 2.2: package hwtools
> Ou est-ce que je risque des corruptions de donn�es ? Je n'ai rien r�ussi �
Il y a *longtemps*, quand Linux �tait un des premiers OS � impl�menter ces
fonctionnalit�s, notamment Quantum ont �t� pris en flagrant d�lit de
pondre du firmware qualit� petit caca, avec corruption de donn�es,
notamment.
Entre temps � mon avis c'est bon pour tous les disques. A ma connaissance
la plupart des AUTRES p�riph�riques (cassettes, ZIP, CDs) n'impl�mentent
pas ces options avanc�es.
Au fait le command queuing est la capacit� d'envoyer plusieurs commandes �
un disque (p.ex. lire N blocks du LBA X, pis aussi lire M blocks du LBA Y)
pour �viter la perte de performance d�e � la s�lection SCSI (par effet de
pipelining/parall�lisation), mais aussi pour permettre au disque, s'il en
a envie, de r�ordonner les commandes.
D'apr�s ce que j'avais vu, en performance s�quentielle brute et en
saturation du bus SCSI, le command queuing peut amener 5-10% de
performances en plus (effet pipelining). Mais augmenter la taille d'IO
aussi. Mais utiliser le `packetized SCSI' aussi (s�lection en mode
synchrone).
Sans saturation, en s�quentiel, cela n'apporte pas grand chose (sauf si le
cache n'est pas activ�, en particulier le prefetch). En r�gime non
s�quentiel, je n'avais jamais vu d'augmentation de performance, mais en
th�orie cela devrait arriver, lorsque p.ex. on peut transf�rer un bloc et
en m�me temps seeker au bloc de la commande suivante.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
