Considérons deux serveurs, chacun ayant un volume raid5 de 1,5 To.
Le second exporte vers le premier (en periphérique bloc) un disque
correspondant à son volume raid5.
J'ai donc un périphérique local /dev/md7 de 1,5 Go en raid5 ainsi
qu'un périphérique iscsi /dev/sdi1 (accessible sans aucun problème).
Je souhaite maintenant répliquer en temps réel le premier disque sur
le seconde avec un mécanisme de type raid1. Je tente donc un :
Root gershwin:[/] > mdadm /dev/md8 -C -l1 -n 2 /dev/md7 /dev/sdc1
mdadm: Cannot open /dev/md7: Device or resource busy
mdadm: Cannot open /dev/sdc1: Device or resource busy
mdadm: create aborted
Root gershwin:[/] >
comme je l'aurais fait sous Solaris.
D'où ma question : peut-on faire du raid sur un périphérique raid ?
Si oui, pourquoi ai-je une telle erreur ?
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
JKB
Le 16-10-2007, à propos de Raid 15 et iscsi, JKB écrivait dans fr.comp.os.linux.moderated :
Bonjour à tous,
Je me réponds, parce qu'avec le délai de la modération ;-) j'ai trouvé un début de solution.
Considérons deux serveurs, chacun ayant un volume raid5 de 1,5 To. Le second exporte vers le premier (en periphérique bloc) un disque correspondant à son volume raid5.
J'ai donc un périphérique local /dev/md7 de 1,5 Go en raid5 ainsi qu'un périphérique iscsi /dev/sdi1 (accessible sans aucun problème). Je souhaite maintenant répliquer en temps réel le premier disque sur le seconde avec un mécanisme de type raid1. Je tente donc un :
Root gershwin:[/] > mdadm /dev/md8 -C -l1 -n 2 /dev/md7 /dev/sdc1 mdadm: Cannot open /dev/md7: Device or resource busy mdadm: Cannot open /dev/sdc1: Device or resource busy mdadm: create aborted Root gershwin:[/] >
comme je l'aurais fait sous Solaris.
D'où ma question : peut-on faire du raid sur un périphérique raid ? Si oui, pourquoi ai-je une telle erreur ?
Il est possible de faire cela, mais il faut rebooter _avant_ les deux serveurs (il y a un effet de bord quelque part, mais je n'ai pas trouvé à quel endroit). Par contre, je récolte du côté du contrôleur un superbe
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 16-10-2007, à propos de
Raid 15 et iscsi,
JKB écrivait dans fr.comp.os.linux.moderated :
Bonjour à tous,
Je me réponds, parce qu'avec le délai de la modération ;-) j'ai
trouvé un début de solution.
Considérons deux serveurs, chacun ayant un volume raid5 de 1,5 To.
Le second exporte vers le premier (en periphérique bloc) un disque
correspondant à son volume raid5.
J'ai donc un périphérique local /dev/md7 de 1,5 Go en raid5 ainsi
qu'un périphérique iscsi /dev/sdi1 (accessible sans aucun problème).
Je souhaite maintenant répliquer en temps réel le premier disque sur
le seconde avec un mécanisme de type raid1. Je tente donc un :
Root gershwin:[/] > mdadm /dev/md8 -C -l1 -n 2 /dev/md7 /dev/sdc1
mdadm: Cannot open /dev/md7: Device or resource busy
mdadm: Cannot open /dev/sdc1: Device or resource busy
mdadm: create aborted
Root gershwin:[/] >
comme je l'aurais fait sous Solaris.
D'où ma question : peut-on faire du raid sur un périphérique raid ?
Si oui, pourquoi ai-je une telle erreur ?
Il est possible de faire cela, mais il faut rebooter _avant_ les
deux serveurs (il y a un effet de bord quelque part, mais je n'ai
pas trouvé à quel endroit). Par contre, je récolte du côté du
contrôleur un superbe
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 16-10-2007, à propos de Raid 15 et iscsi, JKB écrivait dans fr.comp.os.linux.moderated :
Bonjour à tous,
Je me réponds, parce qu'avec le délai de la modération ;-) j'ai trouvé un début de solution.
Considérons deux serveurs, chacun ayant un volume raid5 de 1,5 To. Le second exporte vers le premier (en periphérique bloc) un disque correspondant à son volume raid5.
J'ai donc un périphérique local /dev/md7 de 1,5 Go en raid5 ainsi qu'un périphérique iscsi /dev/sdi1 (accessible sans aucun problème). Je souhaite maintenant répliquer en temps réel le premier disque sur le seconde avec un mécanisme de type raid1. Je tente donc un :
Root gershwin:[/] > mdadm /dev/md8 -C -l1 -n 2 /dev/md7 /dev/sdc1 mdadm: Cannot open /dev/md7: Device or resource busy mdadm: Cannot open /dev/sdc1: Device or resource busy mdadm: create aborted Root gershwin:[/] >
comme je l'aurais fait sous Solaris.
D'où ma question : peut-on faire du raid sur un périphérique raid ? Si oui, pourquoi ai-je une telle erreur ?
Il est possible de faire cela, mais il faut rebooter _avant_ les deux serveurs (il y a un effet de bord quelque part, mais je n'ai pas trouvé à quel endroit). Par contre, je récolte du côté du contrôleur un superbe
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Emmanuel Florac
Le Wed, 17 Oct 2007 19:33:39 +0000, JKB a écrit :
JKB, qui y retourne...
Content de voir que tu t'es résolu à utiliser une solution moderne qui marche, le iSCSI :) En plus d'après la ML de iscsi-target, tu as même trouvé le bug tout seul, tu dois avoir trop de temps libre dans ton boulot :) Après le patch est-ce que ça marche? Pour ma part je n'ai pas rencontré de problème sur beurk^w^w plateforme PC, pour faire du RAID logiciel avec iSCSI d'un côté et du SCSI local de l'autre.
-- Désormais, pour les nations et pour les peuples, une goutte de pétrole a la valeur d'une goutte de sang. Georges Clémenceau.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le Wed, 17 Oct 2007 19:33:39 +0000, JKB a écrit :
JKB, qui y retourne...
Content de voir que tu t'es résolu à utiliser une solution moderne qui
marche, le iSCSI :) En plus d'après la ML de iscsi-target, tu as même
trouvé le bug tout seul, tu dois avoir trop de temps libre dans ton
boulot :) Après le patch est-ce que ça marche? Pour ma part je n'ai pas
rencontré de problème sur beurk^w^w plateforme PC, pour faire du RAID
logiciel avec iSCSI d'un côté et du SCSI local de l'autre.
--
Désormais, pour les nations et pour les peuples, une goutte de pétrole
a la valeur d'une goutte de sang.
Georges Clémenceau.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Content de voir que tu t'es résolu à utiliser une solution moderne qui marche, le iSCSI :) En plus d'après la ML de iscsi-target, tu as même trouvé le bug tout seul, tu dois avoir trop de temps libre dans ton boulot :) Après le patch est-ce que ça marche? Pour ma part je n'ai pas rencontré de problème sur beurk^w^w plateforme PC, pour faire du RAID logiciel avec iSCSI d'un côté et du SCSI local de l'autre.
-- Désormais, pour les nations et pour les peuples, une goutte de pétrole a la valeur d'une goutte de sang. Georges Clémenceau.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 17-10-2007, à propos de Re: Raid 15 et iscsi, Emmanuel Florac écrivait dans fr.comp.os.linux.moderated :
Le Wed, 17 Oct 2007 19:33:39 +0000, JKB a écrit :
JKB, qui y retourne...
Content de voir que tu t'es résolu à utiliser une solution moderne qui marche, le iSCSI :) En plus d'après la ML de iscsi-target, tu as même
Là, je viens de me faire traiter de vieux con, mais passons ;-) Pour information, il y a un bug sournois dans le network block device qui fait que lorsqu'on essaye de construire un raid entre un block device local et un network bloc device, la taille du network block device apparaît 1024 inférieure à la taille réelle, donc la solution simple nbd est tombée à l'eau... Le bug n'est pas dans le code du nbd lui-même mais dans l'appel système du noyau qui renvoie la taille d'un block device... Le code en question est un peu tentaculaire et j'ai laissé tombé.
trouvé le bug tout seul, tu dois avoir trop de temps libre dans ton boulot :)
Pas vraiment, d'ailleurs, ià pas loin de 23h00, j'y suis toujours... Et je suis en train de battre le record du monde du nombre de reboots par heure d'un cluster de T1000 !
Après le patch est-ce que ça marche? Pour ma part je n'ai pas rencontré de problème sur beurk^w^w plateforme PC, pour faire du RAID logiciel avec iSCSI d'un côté et du SCSI local de l'autre.
Je suis d'avis qu'il y a un bug arch specific là-dessous. Le raid6 local fonctionne impécablement sous sparc64, mais le raid5 foirait même en local. Bug corrigé (bug d'ailleurs externe au sous-système raid, le truc a été intégré au 2.6.23-git2 ou 3). Le module iscsi-target n'est franchement pas écrit correctement, et je me demande même comment ce truc pouvait fonctionner quelque part...
Ce que j'aimerais maintenant savoir, surtout au vu de ton expérience iSCSI-esque, ce sont les architectures sur lesquelles le raid1 over iSCSI fonctionne, et celles où il ne fonctionne pas. Cela me permettrait de cibler un peu plus la zone de recherche du bug dans le noyau 2.6.23 (le premier bug trouvé était dans arch/sparc64/lib/xor.s et la lecture attentive de drivers/md/raid5.c me laisse songeur d'autant que c'est du multithreadé qui peut être préemté...).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 17-10-2007, à propos de
Re: Raid 15 et iscsi,
Emmanuel Florac écrivait dans fr.comp.os.linux.moderated :
Le Wed, 17 Oct 2007 19:33:39 +0000, JKB a écrit :
JKB, qui y retourne...
Content de voir que tu t'es résolu à utiliser une solution moderne qui
marche, le iSCSI :) En plus d'après la ML de iscsi-target, tu as même
Là, je viens de me faire traiter de vieux con, mais passons ;-)
Pour information, il y a un bug sournois dans le network block
device qui fait que lorsqu'on essaye de construire un raid entre un
block device local et un network bloc device, la taille du network
block device apparaît 1024 inférieure à la taille réelle, donc la
solution simple nbd est tombée à l'eau... Le bug n'est pas dans le
code du nbd lui-même mais dans l'appel système du noyau qui renvoie
la taille d'un block device... Le code en question est un peu
tentaculaire et j'ai laissé tombé.
trouvé le bug tout seul, tu dois avoir trop de temps libre dans ton
boulot :)
Pas vraiment, d'ailleurs, ià pas loin de 23h00, j'y suis toujours...
Et je suis en train de battre le record du monde du nombre de reboots
par heure d'un cluster de T1000 !
Après le patch est-ce que ça marche? Pour ma part je n'ai pas
rencontré de problème sur beurk^w^w plateforme PC, pour faire du RAID
logiciel avec iSCSI d'un côté et du SCSI local de l'autre.
Je suis d'avis qu'il y a un bug arch specific là-dessous. Le raid6
local fonctionne impécablement sous sparc64, mais le raid5 foirait
même en local. Bug corrigé (bug d'ailleurs externe au sous-système raid,
le truc a été intégré au 2.6.23-git2 ou 3). Le module iscsi-target n'est
franchement pas écrit correctement, et je me demande même comment ce truc
pouvait fonctionner quelque part...
Ce que j'aimerais maintenant savoir, surtout au vu de ton expérience
iSCSI-esque, ce sont les architectures sur lesquelles le raid1 over
iSCSI fonctionne, et celles où il ne fonctionne pas. Cela me
permettrait de cibler un peu plus la zone de recherche du bug dans
le noyau 2.6.23 (le premier bug trouvé était dans arch/sparc64/lib/xor.s
et la lecture attentive de drivers/md/raid5.c me laisse songeur d'autant
que c'est du multithreadé qui peut être préemté...).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 17-10-2007, à propos de Re: Raid 15 et iscsi, Emmanuel Florac écrivait dans fr.comp.os.linux.moderated :
Le Wed, 17 Oct 2007 19:33:39 +0000, JKB a écrit :
JKB, qui y retourne...
Content de voir que tu t'es résolu à utiliser une solution moderne qui marche, le iSCSI :) En plus d'après la ML de iscsi-target, tu as même
Là, je viens de me faire traiter de vieux con, mais passons ;-) Pour information, il y a un bug sournois dans le network block device qui fait que lorsqu'on essaye de construire un raid entre un block device local et un network bloc device, la taille du network block device apparaît 1024 inférieure à la taille réelle, donc la solution simple nbd est tombée à l'eau... Le bug n'est pas dans le code du nbd lui-même mais dans l'appel système du noyau qui renvoie la taille d'un block device... Le code en question est un peu tentaculaire et j'ai laissé tombé.
trouvé le bug tout seul, tu dois avoir trop de temps libre dans ton boulot :)
Pas vraiment, d'ailleurs, ià pas loin de 23h00, j'y suis toujours... Et je suis en train de battre le record du monde du nombre de reboots par heure d'un cluster de T1000 !
Après le patch est-ce que ça marche? Pour ma part je n'ai pas rencontré de problème sur beurk^w^w plateforme PC, pour faire du RAID logiciel avec iSCSI d'un côté et du SCSI local de l'autre.
Je suis d'avis qu'il y a un bug arch specific là-dessous. Le raid6 local fonctionne impécablement sous sparc64, mais le raid5 foirait même en local. Bug corrigé (bug d'ailleurs externe au sous-système raid, le truc a été intégré au 2.6.23-git2 ou 3). Le module iscsi-target n'est franchement pas écrit correctement, et je me demande même comment ce truc pouvait fonctionner quelque part...
Ce que j'aimerais maintenant savoir, surtout au vu de ton expérience iSCSI-esque, ce sont les architectures sur lesquelles le raid1 over iSCSI fonctionne, et celles où il ne fonctionne pas. Cela me permettrait de cibler un peu plus la zone de recherche du bug dans le noyau 2.6.23 (le premier bug trouvé était dans arch/sparc64/lib/xor.s et la lecture attentive de drivers/md/raid5.c me laisse songeur d'autant que c'est du multithreadé qui peut être préemté...).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Emmanuel Florac
Le Wed, 17 Oct 2007 21:17:02 +0000, JKB a écrit :
Le module iscsi-target n'est franchement pas écrit correctement, et je me demande même comment ce truc pouvait fonctionner quelque part...
À ce point? J'ai à peine survolé le code source à un moment, mais je n'ai pas été effrayé...
Ce que j'aimerais maintenant savoir, surtout au vu de ton expérience iSCSI-esque, ce sont les architectures sur lesquelles le raid1 over iSCSI fonctionne, et celles où il ne fonctionne pas.
Malheureusement je n'ai testé que x86 et amd64, et dans les deux cas tout baigne. Comme ma boîte déménage, je suis un peu ploqué pour le moment, mais si possible je tenterai l'installation sur PPC prochainement (trouver un usage à ce vieux mac... :), voire sur MIPS (sur mon Indy) quand j'aurai rebranché mon Octane.
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le Wed, 17 Oct 2007 21:17:02 +0000, JKB a écrit :
Le module iscsi-target n'est
franchement pas écrit correctement, et je me demande même comment ce
truc pouvait fonctionner quelque part...
À ce point? J'ai à peine survolé le code source à un moment, mais je
n'ai pas été effrayé...
Ce que j'aimerais maintenant savoir, surtout au vu de ton expérience
iSCSI-esque, ce sont les architectures sur lesquelles le raid1 over iSCSI
fonctionne, et celles où il ne fonctionne pas.
Malheureusement je n'ai testé que x86 et amd64, et dans les deux cas tout
baigne. Comme ma boîte déménage, je suis un peu ploqué pour le moment,
mais si possible je tenterai l'installation sur PPC prochainement
(trouver un usage à ce vieux mac... :), voire sur MIPS (sur mon Indy)
quand j'aurai rebranché mon Octane.
--
Dix grammes d'abstraction valent des tonnes de bricolage.
Loi de Booker.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le module iscsi-target n'est franchement pas écrit correctement, et je me demande même comment ce truc pouvait fonctionner quelque part...
À ce point? J'ai à peine survolé le code source à un moment, mais je n'ai pas été effrayé...
Ce que j'aimerais maintenant savoir, surtout au vu de ton expérience iSCSI-esque, ce sont les architectures sur lesquelles le raid1 over iSCSI fonctionne, et celles où il ne fonctionne pas.
Malheureusement je n'ai testé que x86 et amd64, et dans les deux cas tout baigne. Comme ma boîte déménage, je suis un peu ploqué pour le moment, mais si possible je tenterai l'installation sur PPC prochainement (trouver un usage à ce vieux mac... :), voire sur MIPS (sur mon Indy) quand j'aurai rebranché mon Octane.
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 18-10-2007, à propos de Re: Raid 15 et iscsi, Emmanuel Florac écrivait dans fr.comp.os.linux.moderated :
Le Wed, 17 Oct 2007 21:17:02 +0000, JKB a écrit :
Le module iscsi-target n'est franchement pas écrit correctement, et je me demande même comment ce truc pouvait fonctionner quelque part...
À ce point? J'ai à peine survolé le code source à un moment, mais je n'ai pas été effrayé...
Disons plus précisément qu'il est convenable presque partout... Certaines opérations sur des pointeurs étaient - comment dire ? - pour le moins baroques ;-)
Ce que j'aimerais maintenant savoir, surtout au vu de ton expérience iSCSI-esque, ce sont les architectures sur lesquelles le raid1 over iSCSI fonctionne, et celles où il ne fonctionne pas.
Malheureusement je n'ai testé que x86 et amd64, et dans les deux cas tout baigne.
Normal, ces deux architectures pouvant utiliser des accès mémoires non alignées, cela ne peut que fonctionner. Sur les architectures où cela ne fonctionnait pas, on se trouvait avec des messages dans la console (problèmes d'alignement mémoire) qui faisait que l'initiateur perdait assez rapidement sa connexion.
Comme ma boîte déménage, je suis un peu ploqué pour le moment, mais si possible je tenterai l'installation sur PPC prochainement (trouver un usage à ce vieux mac... :), voire sur MIPS (sur mon Indy) quand j'aurai rebranché mon Octane.
Sur PPC32, j'ai fait le test : même motif, même punition ;-) Donc si je récapitule :
i386 -> OK amd64 -> OK ppc32 -> NOK sparc32 -> NOK sparc64 -> NOK mips -> à confirmer
Bon, je vais donc creuser deux choses : les problèmes d'alignement mémoire dans drivers/md/ (facile) et les fonctions systèmes de arch/{sparc*mips}, ce qui sera une autre paire de manches... Je ne savais pas quoi faire aujourd'hui ;-)
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 18-10-2007, à propos de
Re: Raid 15 et iscsi,
Emmanuel Florac écrivait dans fr.comp.os.linux.moderated :
Le Wed, 17 Oct 2007 21:17:02 +0000, JKB a écrit :
Le module iscsi-target n'est
franchement pas écrit correctement, et je me demande même comment ce
truc pouvait fonctionner quelque part...
À ce point? J'ai à peine survolé le code source à un moment, mais je
n'ai pas été effrayé...
Disons plus précisément qu'il est convenable presque partout...
Certaines opérations sur des pointeurs étaient - comment dire ? -
pour le moins baroques ;-)
Ce que j'aimerais maintenant savoir, surtout au vu de ton expérience
iSCSI-esque, ce sont les architectures sur lesquelles le raid1 over iSCSI
fonctionne, et celles où il ne fonctionne pas.
Malheureusement je n'ai testé que x86 et amd64, et dans les deux cas tout
baigne.
Normal, ces deux architectures pouvant utiliser des accès mémoires non
alignées, cela ne peut que fonctionner. Sur les architectures où
cela ne fonctionnait pas, on se trouvait avec des messages dans la
console (problèmes d'alignement mémoire) qui faisait que
l'initiateur perdait assez rapidement sa connexion.
Comme ma boîte déménage, je suis un peu ploqué pour le moment,
mais si possible je tenterai l'installation sur PPC prochainement
(trouver un usage à ce vieux mac... :), voire sur MIPS (sur mon Indy)
quand j'aurai rebranché mon Octane.
Sur PPC32, j'ai fait le test : même motif, même punition ;-)
Donc si je récapitule :
i386 -> OK
amd64 -> OK
ppc32 -> NOK
sparc32 -> NOK
sparc64 -> NOK
mips -> à confirmer
Bon, je vais donc creuser deux choses : les problèmes d'alignement
mémoire dans drivers/md/ (facile) et les fonctions systèmes de
arch/{sparc*mips}, ce qui sera une autre paire de manches...
Je ne savais pas quoi faire aujourd'hui ;-)
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 18-10-2007, à propos de Re: Raid 15 et iscsi, Emmanuel Florac écrivait dans fr.comp.os.linux.moderated :
Le Wed, 17 Oct 2007 21:17:02 +0000, JKB a écrit :
Le module iscsi-target n'est franchement pas écrit correctement, et je me demande même comment ce truc pouvait fonctionner quelque part...
À ce point? J'ai à peine survolé le code source à un moment, mais je n'ai pas été effrayé...
Disons plus précisément qu'il est convenable presque partout... Certaines opérations sur des pointeurs étaient - comment dire ? - pour le moins baroques ;-)
Ce que j'aimerais maintenant savoir, surtout au vu de ton expérience iSCSI-esque, ce sont les architectures sur lesquelles le raid1 over iSCSI fonctionne, et celles où il ne fonctionne pas.
Malheureusement je n'ai testé que x86 et amd64, et dans les deux cas tout baigne.
Normal, ces deux architectures pouvant utiliser des accès mémoires non alignées, cela ne peut que fonctionner. Sur les architectures où cela ne fonctionnait pas, on se trouvait avec des messages dans la console (problèmes d'alignement mémoire) qui faisait que l'initiateur perdait assez rapidement sa connexion.
Comme ma boîte déménage, je suis un peu ploqué pour le moment, mais si possible je tenterai l'installation sur PPC prochainement (trouver un usage à ce vieux mac... :), voire sur MIPS (sur mon Indy) quand j'aurai rebranché mon Octane.
Sur PPC32, j'ai fait le test : même motif, même punition ;-) Donc si je récapitule :
i386 -> OK amd64 -> OK ppc32 -> NOK sparc32 -> NOK sparc64 -> NOK mips -> à confirmer
Bon, je vais donc creuser deux choses : les problèmes d'alignement mémoire dans drivers/md/ (facile) et les fonctions systèmes de arch/{sparc*mips}, ce qui sera une autre paire de manches... Je ne savais pas quoi faire aujourd'hui ;-)
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
