On Mon, 23 Apr 2001, you wrote:
> oui, c'est ce qu'on disait avec 10 MByte/s aussi, ou nos clients avec le
> 20 MByte/s, puis le 30 MByte/s ... encore qu'aujourd'hui le besoin a un
> peu baissé vu que les systèmes de compression en vidéo sont très
> communs et performants.
C'est toujours la meme chose. On recoit une machine qui va 5 fois plus vite
que la precedente, on s'extasie... puis avec le temps on finit par trouver
qu'elle traine :-)
> Les premiers 10'000 étaient peu fiables, chauffaient beaucoup, etc.
> Voilà un disque IBM à 15'000 RPM:
Les roulements a billes tournants a 15'000 tours c'est techniquement superbe
! Surtout sans lubrification... Mais au-dela, ca commence a coincer... Il est
normal que ca chauffe. Pour eviter d'avoir du jeux, les roulements doivent
forcement avoir une legere precontrainte (quelques microns, pas plus); mais
ca suffit deja. Il va etre difficile de monter la vitesse de rotation avec
des roulement non auto-lubrifies (et on oublie la lubrification avec des
gouttes d'huile svp !).
> http://www.storage.ibm.com/press/hdd/20010130.htm
>
> vitesse: 647 MBit/s (medium), plus que 52 MByte/s en continu.
> Seek time: 3.4 ms (bon faut savoir ce que ça veut dire).
Average seek time... purement statistique, mais quand meme significatif.
> Effrayant, non ?
IBM a une equipe tres forte dans ce domaine.
> (d'ailleurs le seek time a peu baissé, mes disques en 1990 avaient déjà
> 8-10 ms).
Ah, ah. Le seek time est "directement" fonction de la vitesse de rotation !!!
En effet, combien de temps faut-il pour acceder a un bloc, sachant que
celui-ci vient de passer "sous" la tete de lecture ? Ce qui fait que si l'on
double la vitesse de rotation, on divise par deux le seek time.
Note qu'il y a 20 ans, les disques avaient un AST de 45 ms et des transferts
a 300-500 KB/s. Aujourd'hui, nous avons multiplie le AST d'un ordre de
grandeur seulement... alors que dans le meme temps l'augmentation de la
frequence d'horloge des CPUs a fait un bond d'environ 400.
On peut encore parallelise l'execution des CPU en augmentant ainsi le CPI,
alors que nous arrivons vraiment a une asymptote en ce qui concerne les
disques (concernant les temps d'acces). Passer de 15'000 a 20'000 est un
grand defi technologique. Alors que double le nombre d'unites logique d'un
CPU est beaucoup plus facile.
> Un des gros problèmes du RAID5 c'est le read-modify-write, ce qui pénalise
> l'écriture: pour recalculer la parité. Les systèmes commerciaux trichent
> de différentes façons: une façon est le cache. Mais suivant le `pattern'
> d'accès (en particulier p.ex. si le filesystem est désaligné), si le
> système n'a pas d'algorithme auto-adaptatif, cela ne suffit pas.
>
> Mais si tu présentes des blocs de 4k (soit dit en passant c'est la taille
> au niveau du fs de nos jours sur les gros disques, et aussi la taille de
> page sur ix86),
Comme par hasard ! D'ailleurs il me semble que tous les UNIX ont des tailles
de pages de 4K et la memem taille de blocs sur les disques. La taille des
pages peut etre modifiees dans HP-UX, mais cela est reserve a des
applications tres particulieres (systemes dedies).
> dans ce cas une configuration à 9 disques (8 disques de
> données, 1 disque de parité) peut fonctionner à 100% de la performance
> (soit 800% par rapport à un disque) sans read-modify-write cycle.
Mais... il me semble que l'on continue a ecrire un bloc de 4K par disque. Ce
qui fait qu'un fichier contenant un byte utilisera 32 KB. C'est d'ailleurs la
raison pour laquelle on recommande ce genre d'utilisation seulement pour les
applications utilisant de "gros" fichiers. Remarque que sachant que "hello
world !" sous "Word" uccupe plus de 32 KB...:-)
> Personnellement je crois plus à un concept différent, qui est de
> s'affranchir, au niveau de l'OS, du concept de bloc device, et donner des
> bouts de fichiers au système de stockage qui s'arrange pour le stocker de
> la meilleure façon. Un peu comme un serveur de fichier, mais implémenté
> dans un disque. Sauf erreur Fujitsu ont une fois montré un embedded Linux
> sur un disque.
Mais y-a-t-il des projets en cours pour des serveusr de ce type ? Des trucs
du genre File System Agregation acceder a l'aide d'un bus rapide ? Je sais
que le protocole de Fiber Channel permet un dialogue entre CPUS, mais je n'ai
encore rien vu a ce sujet.
> Il y a aussi GFS http://www.globalfilesystem.org qui promet beaucoup dans
> l'interconnexion et la fiabilité.
Je vais aller y jeter un coup d'oeil.
Daniel
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
