Plusieurs têtes de lecture/écriture indépendantes sur le même plateau de disque dur ?

En 1986, j'ai conçu un système primitif mais efficace de stockage de fichiers d'images à grande vitesse pour utiliser les lecteurs de disques commerciaux de Digital Equipment Corp. en utilisant leur premier système de stockage de disques et d'ordinateurs en grappe basé sur le HSC50. Plutôt que d'utiliser les coûteux systèmes à têtes parallèles capables du débit de données dont nous avions besoin pour stocker les fichiers d'images ASARS-2 U2 RADAR en temps réel pour servir simultanément un processus d'écriture sur la sortie d'un ordinateur VAX 8600, tandis que l'autre ordinateur VAX 8600 avait plusieurs lecteurs de processus simultanés. Nous avons atteint le taux nécessaire en jetant le système de fichiers de Dec, en utilisant des entrées-sorties directes en file d'attente à partir de processus verrouillés en mémoire physique, en écrivant sur un seul (sur 16) lecteur de disque inactif au repos à la fois, prêt à écrire de grands blocs de disque contigus, en laissant 4 ou 5 autres lecteurs de disque lire ces fichiers contigus de manière similaire, Un processus par disque pour ne pas interférer avec les mouvements de tête des autres, et un logiciel d'arbitrage construit pour que tous les disques soient utilisés par une seule activité à la fois, et partagés de manière à ce que les images écrites entre ces disques soient libres de lecture ou en attente de lecture future. Nous avons atteint des taux de données de disque physique pour notre système de fichiers qui correspondaient aux développeurs de systèmes de stockage de DEC de leurs lecteurs RM60 à Colorado Springs selon leur visite à notre site de l'usine Hughes Culver City. Il a été surpris et a dit des graphiques de mon ami Dave - wow - ceux-ci ressemblent exactement aux nôtres, y compris un blip à 1 ou 2 IO de taille d'écriture.

Les métadonnées - mission, scène, image, numéro de lecteur, bloc physique de départ, taille, etc. - sont conservées sur un lecteur de disque commun à usage unique, extrait du pool de stockage d'images et partagé sans les problèmes d'isolation entre les deux - aucun problème de débit de données.

Nous avons eu de la chance - pas besoin de préserver les images après 2 missions - donc nous avons trouvé un moyen de diviser les choses entre 2, et nous avons simplement jeté les fichiers / données de l'ancienne 2ème mission tout en préparant juste avant la suivante. Nous n'avons pas eu besoin de nous pencher sur la question classique de combler le trou dans le système de fichiers. Il y avait une solution facile à cela en utilisant des allocations de taille fixe, si nécessaire, entre les 3 tailles de fichiers d'image du mode RADAR. Il s'agissait donc de circonstances particulières. Propriété du bureau du programme U2, puisque nous avons développé tout cela avec des fonds contractuels - pas de brevets. Fourni à un autre entrepreneur pour le système de collecte d'un autre pays également.

Le seul lecteur dont nous avions connaissance à l'époque et qui était conçu pour des débits de données élevés était un lecteur à têtes multiples par plateau, appelé je crois lecteur de disque IBIS, développé pour les agences gouvernementales. Nous n'avons pas poursuivi les recherches sur ce sujet car nous savions dès le départ, grâce à une simple expérience de laboratoire, que nous pouvions faire ce que nous avons finalement fait. Notre débit de données se situait probablement dans la zone intermédiaire du no-man's point aussi - ce lecteur développé pour la capture de données d'un autre actif.

C'était notre réponse pour obtenir 1.x M-Bytes par seconde soutenu, à l'époque. Ooooh. Wow.... On dit aujourd'hui ! Ce qu'on faisait pour une barre Klondike à l'époque.

J'ai eu l'idée qu'un jeu de bras pourrait être dédié à la surface supérieure du plateau, tandis qu'un second jeu pourrait être exclusivement dédié à l'autre côté. Cela créerait essentiellement un mini RAID 0 ou RAID 1 à l'intérieur du disque, et serait une alternative décente à un disque dur unique avec plusieurs broches ( http://www.google.com/patents/US20060044663 ), car il permettrait d'économiser de l'énergie (puisqu'un seul moteur serait nécessaire), mais présenterait les mêmes avantages en termes de performances que l'entraînement "multibroche" mentionné précédemment.

Trouver de la place dans l'enceinte pour une deuxième bobine mobile et un jeu de bras s'avérerait toutefois difficile, comme David l'a mentionné précédemment. Cependant, une bobine mobile plus petite pourrait résoudre le problème ; le plateau pourrait simplement être déplacé au centre géométrique du lecteur, vu du haut ou du bas, et les bobines mobiles pourraient être positionnées dans les coins opposés. Une bobine mobile suffisamment petite peut déjà exister, mais une bobine plus petite POURRAIT être trop faible pour déplacer les bras avec précision, ce qui introduit un nouveau problème... Je suis sûr que cela pourrait être fait, cependant ; regardez comment les ordinateurs en général sont devenus beaucoup plus petits au fil des ans, après tout.

Une meilleure géométrie pour de multiples têtes de lecture/écriture indépendantes devrait être une géométrie de plaque cylindrique creuse au lieu de plateaux ronds réels. Vous pouvez mettre beaucoup plus de têtes à l'intérieur, le mouvement des têtes sera plus précis permettant une plus grande densité de bits par pouce. En laissant plus d'espace à la hauteur du disque et en plaçant plusieurs cylindres creux de rayon différent les uns dans les autres, la densité de l'espace octet peut être augmentée de façon spectaculaire. Un monstre d'un pentaoctet par 10 centimètres de hauteur/10 centimètres de largeur et 10 cylindres à l'intérieur peut être fabriqué avec la technologie actuelle. Et dans cet espace, vous pouvez placer de nombreuses têtes de lecture indépendantes.

Cylindre creux (géométrie)