Bonjour,
Je viens de récupérer une machine qui partait à la casse.
Elle a un Céléron 466MHz, 192mo de ram et un DD de 10go.
J'ai installé Mandriva 2006, avec 500mo de swap et tout marche bien!
J'ai peut-être la possibilité de remplacer le DD 10go par un 20go.
Est-ce que ce changement va accélérer le chargement de gros fichiers de
présentation sxi. d'Open Office? Ou faut-il mettre un DD beaucoup plus gros
(80mo) pour voir une différence?
Merci pour vos avis.
Daniel
Le 15 January 2006 à 09:49, Daniel Doumenge a dit :
Bonjour, Je viens de récupérer une machine qui partait à la casse. Elle a un Céléron 466MHz, 192mo de ram et un DD de 10go. J'ai installé Mandriva 2006, avec 500mo de swap et tout marche bien!
Ce qu'il y a de bien avec Linux, c'est que comme ça exploite de façon plus efficace et plus économe le matériel , c'est capable de redonner une nouvelle jeunesse à un poste qui n'est pas capable d'exploiter un Windows XP. Quand j'avais 512 Mo de RAM, ma machine ne swappait déjà plus.
J'ai peut-être la possibilité de remplacer le DD 10go par un 20go. Est-ce que ce changement va accélérer le chargement de gros fichiers de présentation sxi. d'Open Office? Ou faut-il mettre un DD beaucoup plus gros (80mo) pour voir une différence? Merci pour vos avis.
C'est pas la taille qui compte, c'est bien connu :) Sérieusement ce qui pourrait faire une différence, c'est d'utiliser un disque supportant l'accès dma ou udma (on peut vérifier les caractéristiques du disque avec hdparm -i /dev/hda (ou hdb, hdc, hdd suivant le cas)
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros. Les disques avec un buffer de 8Mo améliorent grandement les choses.
Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose. -- Sébastien Kirche
Le 15 January 2006 à 09:49, Daniel Doumenge a dit :
Bonjour, Je viens de récupérer une machine qui partait à la casse.
Elle a un Céléron 466MHz, 192mo de ram et un DD de 10go. J'ai installé
Mandriva 2006, avec 500mo de swap et tout marche bien!
Ce qu'il y a de bien avec Linux, c'est que comme ça exploite de façon
plus efficace et plus économe le matériel , c'est capable de redonner
une nouvelle jeunesse à un poste qui n'est pas capable d'exploiter un
Windows XP. Quand j'avais 512 Mo de RAM, ma machine ne swappait déjà
plus.
J'ai peut-être la possibilité de remplacer le DD 10go par un 20go.
Est-ce que ce changement va accélérer le chargement de gros fichiers
de présentation sxi. d'Open Office? Ou faut-il mettre un DD beaucoup
plus gros (80mo) pour voir une différence?
Merci pour vos avis.
C'est pas la taille qui compte, c'est bien connu :)
Sérieusement ce qui pourrait faire une différence, c'est d'utiliser un
disque supportant l'accès dma ou udma (on peut vérifier les
caractéristiques du disque avec
hdparm -i /dev/hda (ou hdb, hdc, hdd suivant le cas)
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou
5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros.
Les disques avec un buffer de 8Mo améliorent grandement les choses.
Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
--
Sébastien Kirche
Le 15 January 2006 à 09:49, Daniel Doumenge a dit :
Bonjour, Je viens de récupérer une machine qui partait à la casse. Elle a un Céléron 466MHz, 192mo de ram et un DD de 10go. J'ai installé Mandriva 2006, avec 500mo de swap et tout marche bien!
Ce qu'il y a de bien avec Linux, c'est que comme ça exploite de façon plus efficace et plus économe le matériel , c'est capable de redonner une nouvelle jeunesse à un poste qui n'est pas capable d'exploiter un Windows XP. Quand j'avais 512 Mo de RAM, ma machine ne swappait déjà plus.
J'ai peut-être la possibilité de remplacer le DD 10go par un 20go. Est-ce que ce changement va accélérer le chargement de gros fichiers de présentation sxi. d'Open Office? Ou faut-il mettre un DD beaucoup plus gros (80mo) pour voir une différence? Merci pour vos avis.
C'est pas la taille qui compte, c'est bien connu :) Sérieusement ce qui pourrait faire une différence, c'est d'utiliser un disque supportant l'accès dma ou udma (on peut vérifier les caractéristiques du disque avec hdparm -i /dev/hda (ou hdb, hdc, hdd suivant le cas)
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros. Les disques avec un buffer de 8Mo améliorent grandement les choses.
Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose. -- Sébastien Kirche
R12y
Sébastien Kirche :
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros. Les disques avec un buffer de 8Mo améliorent grandement les choses. Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
Et encore, imagine les perfs si il passe carrément au scsi! :-)
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou
5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros.
Les disques avec un buffer de 8Mo améliorent grandement les choses.
Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
Et encore, imagine les perfs si il passe carrément au scsi! :-)
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros. Les disques avec un buffer de 8Mo améliorent grandement les choses. Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
Et encore, imagine les perfs si il passe carrément au scsi! :-)
J'ai peut-être la possibilité de remplacer le DD 10go par un 20go. Est-ce que ce changement va accélérer le chargement de gros fichiers
La taille du disque elle-même, aura peut-être pour effet de réduire la fragmentation des fichiers, mais j'ai bien peur que ce soit marginal. Sinon, à moins que ton 10Go ait été un 10Go haut de gamme et le 20Go un bas de gamme, il y a quand même de bonnes chances pour que le 20Go supporte une vitesse de transfert un peu plus élevée. Bref, c'est à tester...
Daniel Doumenge :
J'ai peut-être la possibilité de remplacer le DD 10go par un 20go.
Est-ce que ce changement va accélérer le chargement de gros fichiers
La taille du disque elle-même, aura peut-être pour effet de réduire la
fragmentation des fichiers, mais j'ai bien peur que ce soit marginal. Sinon,
à moins que ton 10Go ait été un 10Go haut de gamme et le 20Go un bas de
gamme, il y a quand même de bonnes chances pour que le 20Go supporte une
vitesse de transfert un peu plus élevée. Bref, c'est à tester...
J'ai peut-être la possibilité de remplacer le DD 10go par un 20go. Est-ce que ce changement va accélérer le chargement de gros fichiers
La taille du disque elle-même, aura peut-être pour effet de réduire la fragmentation des fichiers, mais j'ai bien peur que ce soit marginal. Sinon, à moins que ton 10Go ait été un 10Go haut de gamme et le 20Go un bas de gamme, il y a quand même de bonnes chances pour que le 20Go supporte une vitesse de transfert un peu plus élevée. Bref, c'est à tester...
Emmanuel Fleury
hdparm -tT /dev/hda
Amicalement -- Emmanuel Fleury
I liked things better when I didn't understand them. -- Calvin & Hobbes (Bill Waterson)
hdparm -tT /dev/hda
Amicalement
--
Emmanuel Fleury
I liked things better when I didn't understand them.
-- Calvin & Hobbes (Bill Waterson)
I liked things better when I didn't understand them. -- Calvin & Hobbes (Bill Waterson)
Pascal Hambourg
Salut,
Sébastien Kirche :
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros.
Il ne doit pas y avoir eu beaucoup de disques de 10 Go à moins de 5400 tours/minute, à part pour portables peut-être.
Les disques avec un buffer de 8Mo améliorent grandement les choses. Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
Si le doublement de la capacité est due à un doublement de la densité et pas du nombre de plateaux, il y aura une augmentation non négligeable du débit soutenu, mais peut-être au prix d'une légère augmentation du temps d'accès.
Et encore, imagine les perfs si il passe carrément au scsi! :-)
Apparemment ça dépend de l'utilisation. Si on en croit les comparatifs réalisés à l'occasion du test du WD Raptor 150 Go par Storageview, en mono-utilisateur les disques (S)ATA n'ont rien à envier aux SCSI. Ce n'est qu'en multi-utilisateur que les SCSI se démarquent vraiment.
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou
5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros.
Il ne doit pas y avoir eu beaucoup de disques de 10 Go à moins de 5400
tours/minute, à part pour portables peut-être.
Les disques avec un buffer de 8Mo améliorent grandement les choses.
Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
Si le doublement de la capacité est due à un doublement de la densité et
pas du nombre de plateaux, il y aura une augmentation non négligeable du
débit soutenu, mais peut-être au prix d'une légère augmentation du temps
d'accès.
Et encore, imagine les perfs si il passe carrément au scsi! :-)
Apparemment ça dépend de l'utilisation. Si on en croit les comparatifs
réalisés à l'occasion du test du WD Raptor 150 Go par Storageview, en
mono-utilisateur les disques (S)ATA n'ont rien à envier aux SCSI. Ce
n'est qu'en multi-utilisateur que les SCSI se démarquent vraiment.
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros.
Il ne doit pas y avoir eu beaucoup de disques de 10 Go à moins de 5400 tours/minute, à part pour portables peut-être.
Les disques avec un buffer de 8Mo améliorent grandement les choses. Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
Si le doublement de la capacité est due à un doublement de la densité et pas du nombre de plateaux, il y aura une augmentation non négligeable du débit soutenu, mais peut-être au prix d'une légère augmentation du temps d'accès.
Et encore, imagine les perfs si il passe carrément au scsi! :-)
Apparemment ça dépend de l'utilisation. Si on en croit les comparatifs réalisés à l'occasion du test du WD Raptor 150 Go par Storageview, en mono-utilisateur les disques (S)ATA n'ont rien à envier aux SCSI. Ce n'est qu'en multi-utilisateur que les SCSI se démarquent vraiment.
C'est pas la taille qui compte, c'est bien connu :)
Pas directement, non. Mais des caractéristiques qui influent sur la taille peuvent influer sur les performances.
Sérieusement ce qui pourrait faire une différence, c'est d'utiliser un disque supportant l'accès dma ou udma
Je ne connais aucun disque ATA de génération compatible avec une capacité de 10 Go qui ne supporte pas de mode (U)DMA. Cela serait proprement suicidaire compte tenu des performances minables des contrôleurs hôtes PCI ATA en mode PIO.
C'est pas la taille qui compte, c'est bien connu :)
Pas directement, non. Mais des caractéristiques qui influent sur la
taille peuvent influer sur les performances.
Sérieusement ce qui pourrait faire une différence, c'est d'utiliser un
disque supportant l'accès dma ou udma
Je ne connais aucun disque ATA de génération compatible avec une
capacité de 10 Go qui ne supporte pas de mode (U)DMA. Cela serait
proprement suicidaire compte tenu des performances minables des
contrôleurs hôtes PCI ATA en mode PIO.
C'est pas la taille qui compte, c'est bien connu :)
Pas directement, non. Mais des caractéristiques qui influent sur la taille peuvent influer sur les performances.
Sérieusement ce qui pourrait faire une différence, c'est d'utiliser un disque supportant l'accès dma ou udma
Je ne connais aucun disque ATA de génération compatible avec une capacité de 10 Go qui ne supporte pas de mode (U)DMA. Cela serait proprement suicidaire compte tenu des performances minables des contrôleurs hôtes PCI ATA en mode PIO.
Pascal Hambourg
hdparm -tT /dev/hda
Ne mesure que le débit soutenu au début du disque, soit une toute petite partie des performances du disques. En utilisation réelle, le temps d'accès, la taille du cache, la sophistication du firmware ont une grande influence qui n'est pas mesurable par hdparm.
hdparm -tT /dev/hda
Ne mesure que le débit soutenu au début du disque, soit une toute petite
partie des performances du disques. En utilisation réelle, le temps
d'accès, la taille du cache, la sophistication du firmware ont une
grande influence qui n'est pas mesurable par hdparm.
Ne mesure que le débit soutenu au début du disque, soit une toute petite partie des performances du disques. En utilisation réelle, le temps d'accès, la taille du cache, la sophistication du firmware ont une grande influence qui n'est pas mesurable par hdparm.
R12y
Pascal Hambourg :
Et encore, imagine les perfs si il passe carrément au scsi! :-) Apparemment ça dépend de l'utilisation. Si on en croit les comparatifs
réalisés à l'occasion du test du WD Raptor 150 Go par Storageview, en mono-utilisateur les disques (S)ATA n'ont rien à envier aux SCSI. Ce n'est qu'en multi-utilisateur que les SCSI se démarquent vraiment. Comparaison mono-utilisateur : http://www.storagereview.com/articles/200601/WD1500ADFD_4.html Comparaison multi-utilisateur : http://www.storagereview.com/articles/200601/WD1500ADFD_6.html
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu dans les tests. Par exemple, (sous Linux) si je rippe deux CD audio en même temps (j'ai deux lecteur de CDrom) et que pourtant je suis le seul utilisateur du PC, c'est compté comment? De plus, sous Linux on n'est jamais le seul utilisateur en vrai. Par exemple:
Et encore, imagine les perfs si il passe carrément au scsi! :-)
Apparemment ça dépend de l'utilisation. Si on en croit les comparatifs
réalisés à l'occasion du test du WD Raptor 150 Go par Storageview, en
mono-utilisateur les disques (S)ATA n'ont rien à envier aux SCSI. Ce
n'est qu'en multi-utilisateur que les SCSI se démarquent vraiment.
Comparaison mono-utilisateur :
http://www.storagereview.com/articles/200601/WD1500ADFD_4.html
Comparaison multi-utilisateur :
http://www.storagereview.com/articles/200601/WD1500ADFD_6.html
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu
dans les tests.
Par exemple, (sous Linux) si je rippe deux CD audio en même temps (j'ai
deux lecteur de CDrom) et que pourtant je suis le seul utilisateur du PC,
c'est compté comment?
De plus, sous Linux on n'est jamais le seul utilisateur en vrai. Par
exemple:
Et encore, imagine les perfs si il passe carrément au scsi! :-) Apparemment ça dépend de l'utilisation. Si on en croit les comparatifs
réalisés à l'occasion du test du WD Raptor 150 Go par Storageview, en mono-utilisateur les disques (S)ATA n'ont rien à envier aux SCSI. Ce n'est qu'en multi-utilisateur que les SCSI se démarquent vraiment. Comparaison mono-utilisateur : http://www.storagereview.com/articles/200601/WD1500ADFD_4.html Comparaison multi-utilisateur : http://www.storagereview.com/articles/200601/WD1500ADFD_6.html
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu dans les tests. Par exemple, (sous Linux) si je rippe deux CD audio en même temps (j'ai deux lecteur de CDrom) et que pourtant je suis le seul utilisateur du PC, c'est compté comment? De plus, sous Linux on n'est jamais le seul utilisateur en vrai. Par exemple:
Apparemment ça dépend de l'utilisation. Si on en croit les comparatifs réalisés à l'occasion du test du WD Raptor 150 Go par Storageview, en mono-utilisateur les disques (S)ATA n'ont rien à envier aux SCSI. Ce n'est qu'en multi-utilisateur que les SCSI se démarquent vraiment.
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu dans les tests.
La différence est brièvement exposée au début de la page du test de simulation multi-utilisateur :
Par exemple, (sous Linux) si je rippe deux CD audio en même temps (j'ai deux lecteur de CDrom) et que pourtant je suis le seul utilisateur du PC, c'est compté comment?
Mono. Le rip de CD, pour un disque dur, c'est typiquement de l'écriture continue à faible débit (limité par la source). Seul le débit soutenu en écriture est sollicité. C'est vraiment ce qu'on peut trouver de moins exigeant pour un disque dur. Ça n'a rien en commun avec un serveur qui doit servir des dizaines de requêtes simultanément générant autant d'accès disques aléatoires.
De plus, sous Linux on n'est jamais le seul utilisateur en vrai.
Mais combien de ces "utilisateurs" provoquent-ils des accès disques permanents ?
Apparemment ça dépend de l'utilisation. Si on en croit les comparatifs
réalisés à l'occasion du test du WD Raptor 150 Go par Storageview, en
mono-utilisateur les disques (S)ATA n'ont rien à envier aux SCSI. Ce
n'est qu'en multi-utilisateur que les SCSI se démarquent vraiment.
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu
dans les tests.
La différence est brièvement exposée au début de la page du test de
simulation multi-utilisateur :
Par exemple, (sous Linux) si je rippe deux CD audio en même temps (j'ai
deux lecteur de CDrom) et que pourtant je suis le seul utilisateur du PC,
c'est compté comment?
Mono. Le rip de CD, pour un disque dur, c'est typiquement de l'écriture
continue à faible débit (limité par la source). Seul le débit soutenu en
écriture est sollicité. C'est vraiment ce qu'on peut trouver de moins
exigeant pour un disque dur. Ça n'a rien en commun avec un serveur qui
doit servir des dizaines de requêtes simultanément générant autant
d'accès disques aléatoires.
De plus, sous Linux on n'est jamais le seul utilisateur en vrai.
Mais combien de ces "utilisateurs" provoquent-ils des accès disques
permanents ?
Apparemment ça dépend de l'utilisation. Si on en croit les comparatifs réalisés à l'occasion du test du WD Raptor 150 Go par Storageview, en mono-utilisateur les disques (S)ATA n'ont rien à envier aux SCSI. Ce n'est qu'en multi-utilisateur que les SCSI se démarquent vraiment.
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu dans les tests.
La différence est brièvement exposée au début de la page du test de simulation multi-utilisateur :
Par exemple, (sous Linux) si je rippe deux CD audio en même temps (j'ai deux lecteur de CDrom) et que pourtant je suis le seul utilisateur du PC, c'est compté comment?
Mono. Le rip de CD, pour un disque dur, c'est typiquement de l'écriture continue à faible débit (limité par la source). Seul le débit soutenu en écriture est sollicité. C'est vraiment ce qu'on peut trouver de moins exigeant pour un disque dur. Ça n'a rien en commun avec un serveur qui doit servir des dizaines de requêtes simultanément générant autant d'accès disques aléatoires.
De plus, sous Linux on n'est jamais le seul utilisateur en vrai.
Mais combien de ces "utilisateurs" provoquent-ils des accès disques permanents ?
Calimero
R12y wrote:
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu dans les tests.
Il est sans doute plus question de "multiples acces aléatoires" que multi utilisateur au sens "who".
Avec un site web qui sert des dizaines de pages/fichiers par seconde, avec en plus des accès en base de données, tu te retrouves avec un disque qui croule sous de nombreuses requetes simultanées. Là dessus, les disques SCSI à 15 000tr/min gagnent sur le plan des temps d'accès (on doit etre quasiment à la moitié d'un disque à 7200tr/min). Le SCSI a aussi une gestion des files d'attentes: les requetes de la file sont réordonnées pour pouvoir servir les données avec le moins de "tours de disque" possible. Une telle technique débarque en SATA désormais (NCQ) mais il doit y avoir encore quelques optimisations à apporter et il faut des controleurs qui supportent. Et comme tu le vois dans les liens fournis par Pascal, le NCQ n'est utile que dans le cas d'accès hautement aléatoires et concurrentiels.
Sinon, il semblerait que les mécaniques SCSI soient orientées pour de l'opération 24x7 avec des MTBF supérieurs (mais on s'en fout pour les perfs).
Bref, c'est comme toujours une question d'utilisation: s'il s'agit de faire des accès fortement séquenciels sur de gros fichiers en environnement peu concurrentiel (genre montage de fichiers vidéo), un bon gros disque ATA doit faire l'affaire, voire un RAID.
Par contre dans une contexte fortement concurrentiel (un serveur, quoi), le SCSI tient encore le haut du pavé.
Après, y a toujours le facteur tune.
-- @+ Calimero
R12y wrote:
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu
dans les tests.
Il est sans doute plus question de "multiples acces aléatoires" que
multi utilisateur au sens "who".
Avec un site web qui sert des dizaines de pages/fichiers par seconde,
avec en plus des accès en base de données, tu te retrouves avec un
disque qui croule sous de nombreuses requetes simultanées.
Là dessus, les disques SCSI à 15 000tr/min gagnent sur le plan des
temps d'accès (on doit etre quasiment à la moitié d'un disque à
7200tr/min).
Le SCSI a aussi une gestion des files d'attentes: les requetes de la
file sont réordonnées pour pouvoir servir les données avec le moins de
"tours de disque" possible. Une telle technique débarque en SATA
désormais (NCQ) mais il doit y avoir encore quelques optimisations à
apporter et il faut des controleurs qui supportent.
Et comme tu le vois dans les liens fournis par Pascal, le NCQ n'est
utile que dans le cas d'accès hautement aléatoires et concurrentiels.
Sinon, il semblerait que les mécaniques SCSI soient orientées pour de
l'opération 24x7 avec des MTBF supérieurs (mais on s'en fout pour les
perfs).
Bref, c'est comme toujours une question d'utilisation: s'il s'agit de
faire des accès fortement séquenciels sur de gros fichiers en
environnement peu concurrentiel (genre montage de fichiers vidéo), un
bon gros disque ATA doit faire l'affaire, voire un RAID.
Par contre dans une contexte fortement concurrentiel (un serveur,
quoi), le SCSI tient encore le haut du pavé.
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu dans les tests.
Il est sans doute plus question de "multiples acces aléatoires" que multi utilisateur au sens "who".
Avec un site web qui sert des dizaines de pages/fichiers par seconde, avec en plus des accès en base de données, tu te retrouves avec un disque qui croule sous de nombreuses requetes simultanées. Là dessus, les disques SCSI à 15 000tr/min gagnent sur le plan des temps d'accès (on doit etre quasiment à la moitié d'un disque à 7200tr/min). Le SCSI a aussi une gestion des files d'attentes: les requetes de la file sont réordonnées pour pouvoir servir les données avec le moins de "tours de disque" possible. Une telle technique débarque en SATA désormais (NCQ) mais il doit y avoir encore quelques optimisations à apporter et il faut des controleurs qui supportent. Et comme tu le vois dans les liens fournis par Pascal, le NCQ n'est utile que dans le cas d'accès hautement aléatoires et concurrentiels.
Sinon, il semblerait que les mécaniques SCSI soient orientées pour de l'opération 24x7 avec des MTBF supérieurs (mais on s'en fout pour les perfs).
Bref, c'est comme toujours une question d'utilisation: s'il s'agit de faire des accès fortement séquenciels sur de gros fichiers en environnement peu concurrentiel (genre montage de fichiers vidéo), un bon gros disque ATA doit faire l'affaire, voire un RAID.
Par contre dans une contexte fortement concurrentiel (un serveur, quoi), le SCSI tient encore le haut du pavé.
