Salut à tous,

je connais un minimum le script Linux, et on me questionne sur un projet somme toute pas très complexe qui à priori nécessite du script, ne connaissant pas de soft collant aux besoins. Et j'avoue avoir répondu "euh là c'est chaud je me renseigne''...

Topo
Effectuer des copies d'une grande quantité de données, disons 200Go pour notre exemple, vers de multiples destinations.
Autrement dit, copier tout le contenu d'un disque (donc un /dev/sd(x)) vers de multiples disques.
Quand je dis multiples disques destination, c'est plein plein, genre 30 pour notre exemple.
Toujours pour l'exemple, considérons le disque source /dev/sds, et les disques destinations /dev/sdd1, /dev/sdd2 ... /dev/sdd30
Pour les estimations de temps, considérons qu'une copie prend une heure.
Coté hardware, je connais bien c'est pas le soucis, y a tout ce qu'il faut (j'aurais juste une question sur l'automount mais on verra plus tard, détail)

Problème
Les performances. En effet, vous répondrez ''ben tu fais un script qui lance autant de ''cp -r'' ou de ''dd'' que nécessaire. Mais non. Pourquoi non ?
Parce que les performances ne conviennent pas, parce que les multiples process de lecture (autant que de disque destination) créeront masse d'accès concurrents sur la source (un disque dur sata), ce qui écroulera ses perfs (je peux détailler le pourquoi si besoin). Note : une source en ssd ne change pas grand chose, on restera limité au débit du ssd au mieux (et on sera loin du mieux).
Lancer les copies une par une ou deux par deux ? Peut mieux faire...

J'ai donc pensé vite fait à une solution, enfin plutôt à deux et c'est pour la deuxième que peut être les cracks parmi vous peuvent aider...
A- Copie pyramidale
1. On copie /dev/sds vers /dev/sdd1 : Une heure
2. On copie /dev/sds vers /dev/sdd2 et /dev/sdd1 vers /dev/sdd3 : Une heure
3. On copie :
/dev/sds vers /dev/sdd4
/dev/sdd1 vers /dev/sdd5
/dev/sdd2 vers /dev/sdd6
/dev/sdd3 vers /dev/sdd7

.......et vous comprenez le principe, on continue comme ça jusqu'au bout.

Chaque heure on multiplie nos sources par deux. Pour 30 copies ça prendra 5h, pas mal.
Le script est coton mais ça se joue. Je conseillerai cette direction à priori.

Mais ne peut on pas mieux faire ?

B- Méthode staïly
Bien plus élégante et performante. Elle consiste à lire sur la source une certaine quantité de donnée (genre 10Mo), une fois, poser ces données en RAM, puis lancer une écriture de ce ''bloc'' sur tous les /dev/sdd en même temps (ce qui donnera des performances excellentes, proportionnelles au nombre de disques destination).

Je bossais un peu sous IRIX (SGI Unix)  il y a longtemps, pas mal plus permissif que Linux. On pouvait effectuer des opération de bas niveau via des softs genre ''dd'' de Linux, et entre autre écrire sur plusieurs dev à partir d'une même source.

Alors messieurs, vous y êtes, Linux proposerait il une solution ?? Je fouille les man de dd et d'autres forums depuis une heure, pas très concluant...

merci beaucoup et bonne journée à tous !

Salut,
 
Tu es obligé de gérer ça au niveau disque? tu peux pas le faire au niveau ordinateur via un soft client-serveur ?
 
Quand j'avais du dupliquer des installations de soft on m'avait justement conseillé d'utiliser un serveur qui contient l'image à copier (ou dans ton cas, le HDD) et plusieurs ordinateurs "clients" qui viendraient demander l'image en question. Le benef c'est que tu peux faire du multicast => Tu lis une seule fois les data sur tes HDD , et tous les ordi les lisent en // . Par contre t'as interet à avoir du câble gigabit (ou mieux, fibre optique) à portée de main pour que ça débite bien.

ben qq soit la méthode de copie ''haut niveau'' utilisée (client /serveur, connexion 1000000Gbps, Fibre intergalactique ou autre), le problème est que le nombre d'IO bas niveau de lecture simultané demandé à la source (ici un seul et unique disque dur) est trop important : débit de merde.

Là un type me recommande de chercher autour de l'idée du ramdisk : créer un ramdisk de 16Mo par exemple, lire via dd sur la source et copier sur ce ram disk. Puis lancer pleins de dd depuis ce ramdisk vers les destinations, comme on lit dans la ram les perfs d'accès concurent sont excellentes. La difficulté est de scripter une copie d'un fichier de 200Go par ''tranches de 16Mo''...

un truc genre

ferait pas l'affaire ?
 
Me demande pourquoi il est pas installé par défaut ce tpipe, très pratique !

multicast, pareil

Bon merci pour vos réponses mais je crois que je tiens ma soluce suite à l'idée d'un Polonais sur un forum :

création d'une /dev en ram, 16Mo suffisent
grâce à dd, lecture d'une tranche de 5Mo sur ma source, écriture dans le ramdrive
copie de cette tranche de 5Mo vers toutes les destinations via dd.
lecture de la tranche de 5Mo suivante de ma source (via paramètre skip de dd), écriture dans le ramdrive
copie de cette tranche suivante via les paramètres oflag=append et seek=offset de dd, sur toutes les destinations.

Avec un disque sata 80Go Maxtor 5 ans d'age en source et 6 disques sata 250Go Hitachi sur contrôleur 3ware 9550sx j'écris déjà à 230Mo/s cumulé... Avec deux contrôleurs et un disque source récent le Go/s sera facile dépassé. 1Go/s c'est l'objectif. Avec cette méthode tant que les contrôleurs / bus PCI ne sont pas saturés une copie vers n disque prend le temps de lecture du fichier source sur son disque source.

Reste à scripter ça pour accepter dynamiquement un nombre n de disques destination, récupérer les /dev/x automatiquement ect mais c'est du gâteau.

Par contre tpipe c'est quoi ce truc ? Je chercherai demain mais si t'as des explications ce soir High Plains Drifter j'accepte...

merci encore bonne soirée à tous !

Tu peux même aller plus vite en utilisant 2 ramdisks utilisés alternativement. Lorsque tu lis l'un tu écris l'autre depuis la source.
 
Ca fonctionnerait de cette façon :
 
écriture sur ramdisk0 depuis sds
écriture sur les disques depuis ramdisk0 & écriture sur ramdisk1 depuis sds
écriture sur les disques depuis ramdisk1 & écriture sur ramdisk0 depuis sds
 
etc. Je pense que tu peux gagner un temps non négligeable.

tpipe duplique l'entrée standard, comme tee mais au lieux d'enregistrer la copie dans un fichier, il la passe a un autre programme passé en argument, ça se rapproche du résultat de la commande dd de IRIX que tu cite dans ton premier post.
En les chaînant comme plus haut on peut dupliquer l'entrée un très grand nombre de fois.
 
Bref dans ton cas ça fait lu une fois, écrit x fois, ça devrait être au final aussi rapide qu'avec un ramdisk.
 
Et quelle que soit la méthode choisie ne pas oublier de vérifier l'intégrité des données au final.

 
Absolument pas    
Je crois que tu as pas capté les tenants et aboutissants du multicast  

Hum, tu peux éventuellement les détailler ?
Ca remonte à mes études mais il me reste quand même des souvenirs : le multicast est un terme réseau (de niveau 3 donc). Il nécessite des routeurs compatibles, de plus je suis pas sûr qu'on puisse assurer l'intégrité des données via le multicast (très orienté vidéo il me semble).
On parle pas de réseau ici de toute façon.
Je suis pas expert en multicast loi de là mais connais juste assez pour savoir que ce n'est pas la solution...
 
Si c'est la solution sort moi le script shell multicast et on en reparle.

évite de prendre un ton hautain, merci.

Accessoirement demande toi pourquoi certaines solutions de ghost à très grande échelle l'utilise.

Parce qu'un déploiement de ghost implique plusieurs ordinateurs différents, reliés entre eux par un réseau ip, loin du contexte ennoncé dans post initial ? (mon frère qui passe son brevet des collèges m'a soufflé la réponse)
Et parlant ''accessoires'' mon ton ferme répond à un post que j'interprète comme hautain (techniquement très vague et hors sujet de surcroit).

Même si il s'est planté sur le contexte tu n'as pas besoin d'être hautain, vu qu'il ne l'a pas été.

j'ai mal interprété, autant pour moi

Salut,
Mon ton était pas hautain, j'ai juste pas compris pourquoi tu as écarté aussi rapidement la solution que je proposais. Effectivement elle n'est pas strictement dans le cadre énoncé initialement, mais j'ai appris avec le temps que des fois, le problème réside justement dans le cadre originalement imaginé..
 
Bref si tu trouves mieux que multicast, je suis content pour toi

et donc... seconde question...
Connaitriez vous un moyen de scripter ça :

a- A la connexion d'un disque (sata), montage automatique (sans confirmation) de ce disque sur un point quelconque (genre si c'est /dev/sda22, monter sur /mnt/sda22). A priori avec l'automount, mais l'automount n'impose t-il pas de connaître à l'avance le /dev/sd? qu'on a connecté ?
b- récupération de la string "/mnt/sda22", par exemple dans un fichier pour utilisation dans le script décrit ci dessus ? (sur ce point je me dis pour l'instant que je parserai le résultat d'un 'df' en excluant toutes les partitions de la bécane quand aucun disque n'est branché).

(question subsidiaire mais comme ça prend peu de temps, faisable à la main : je pense pas que ce soit possible mais en étape juste avant a-, formatage (en ext) du disque automatique sans confirmation)).

merci beaucoup bonne nuit !

Ça doit être possible avec HAL/Dbus récupérer l'event à la connection et formater/monter le disque.

Effectivement c'est possible, faut juste regarder les scripts déjà écrits dans ton rép HAL, c'est assez facile à lire..

Hé dites donc, c'est bien gentil tous mes trucs, mais je bloque sur un détail tout con en automatisant le script qui n'apparaissait pas en testant ''à la mano''.
 
Je m'explique : une fois la ''tranche'' source chargée dans le ramdrive via dd, je dois l'écrire vers de multiples destinations EN PARALLÈLE. En testant à la main j'ai lancé plusieurs dd dans des shell différents, donc no soucy. Mais dans un script, le dd d'écriture vers la deuxième destination devra attendre la fin du dd vers la première destination... Ce qui bousille toutes les perfs.
 
Comment lancer des commandes shell sans attendre la fin de la commande précédente ?
 
merci encore de votre aide bonne soirée !
 

utilise &

yes merci beaucoup, ça avance avec &...
 
Mais je tombe sur un problème :
 
dans la boucle qui écrit la tranche depuis le ramdrive vers les disques destination, se lancent pleins de dd, simultanés, grâce à &.
Mais pour le coup, la boucle se termine et le script poursuit son exécution en passant à la lecture de la tranche suivante, AVANT que tous les dd d'écriture sur les disques destination soient terminés ! Je me retrouve donc avec certains fichiers destination corrompus...
Je confirme cette hypothèse par l'utilisation d'une commande "sleep 2" pour ralentir la boucle, et là les fichiers ne sont jamais corrompus.
Evidemment pour des raisons de perfs, ralentir la boucle ne serait pas envisageable...
 
for destination in liste_des_destinations  
do
ecriture depuis ramdrive vers destination &
done
 
J'imagine qu'il faudrait vérifier que tous les process dd d'écriture ramdrive vers destination sont bien terminés avant de continuer, mais là, je sèche.
 
 
 
 

bienvenue dans le monde du conccurentiel et là il va te falloir plus que du bash

Question conne :  
ça marche pas d'appeler dd depuis un langage qui supporte la notion de thread synchronisés ? Ruby pour n'en nommer qu'un .

j'y connais en Ruby, je crois que je lis ce nom pour la première fois...
Un peu frustrant de bloquer si près du but.
Je cherche autour d'une gestion de threads, mais bon ça parait vachement plus compliqué pour un truc qui devait se régler en quelques lignes de script.
Ca sent la copie pyramidale
 
merci pour votre aide en tout cas bonne soirée à tous

Topic très intéressant

Et la solution que j'ai proposé alors elle pue du cul ?
La sortie standard est bufferisé donc pas de PB de saturation de la mémoire normalement, reste a voir si tpipe casse pas ce bel équilibre.

 
Je sais pas si ça marcherait, mais si une simple gestion synchro de thread suffi, c'est balayé en 5 lignes en ruby hein
Après si tu veux faire toute ta gestion d'erreur & co en ruby, ça rallonge un peu, mais si tout ce que tu veux faire en ruby, c'est gérer le côté thread, ça se fait easy

Je comprends rien à cette histoire de ramdisk à la con: le noyau fait du cache et puis, voilà, il te suffit d'augmenter la taille de bloc de dd pour avoir exactement le même effet.
 
C'est quoi réellement la nécessité de copier comme ça ?
Parce qu'entre du raid, nbd, drdb, nas, san, bittorrent, y a forcément un truc existant qui colle parfaitement.
 
Et en passant, sauf si ta partition est réellement remplie à 100%, t'as tout à gagner à ne pas copier bêtement des blocs. rsync quoi.
 
Et puis dans tous les cas, un coup de compression à la volée (lzop) ça ne peut qu'aider.

Non c'est la meilleure. Tu peux faire ça avec tee si t'as des NBD aussi. Le buffer des pipe, il est quand même petit, quelques pages à tout casser. Sur un noyau récent, tu dois certainement pouvoir faire un truc très bon avec du tee(2)/splice(2) en quelques lignes de C.

 
Histoire de ramdisk à la con ???
''le noyau fait du cache et puis voilà ?" : t'aurais pas tendance à arrondir à 10^12 près toi ?
Raid ? nas, san ??? ''forcément un truc qui colle parfaitement ?". no comment...
Compression à la volée pourquoi faire ? Non ça n'aide en rien, le problème de perfs provient d'un trop grand nombre d'accès simultané sur une source mécanique, pas d'un problème de débit ou bande passante.
Prend une source de 200Go, copie là en // sur 30 destinations, tu comprendras (débit par destination : moins de 1Mo/s).
Comme indique sur le premier post si tu souhaites obtenir des détails sur le phénomène il faut demander
 
Ceci dit je cherche du coté de tee, comme je connais pas cette commande et que je suis flemmard  je l'avais mise de coté...
 
Sinon j'ai pensé à une solution bourrin et dégueulasse au possible (avec des sleep), qui ralentissent la copie certes d'environ 10%-15%, ce qui vaudrait quand même le coup au final...
 
Je vous tiens au jus !

De plus en plus

 
Le problème, c'est que (en tout cas pour ma part) tu ne détailles pas l'archi matérielle qui se trouve derrière.
 
De tes posts, la seule chose que j'en retire c'est : 1 source, 30 destinations. Et à peine une vague idée que les disques sont peut-être sur la même machine, et encore, c'est pas explicite puisque quand on te parle de multicast, tu ne rejettes pas franchement l'idée.
 
Détaille tout ça et tu auras moins de réponses qui te semblent hors sujet.

Pas faux... Voici une description de l'archi matérielle prévue, bien qu'elle ne soit pas figée précisément, on reste dans le concept global suivant :

- une seule source au départ, 200Go en moyenne et un seul gros fichier. Située sur un support hard à définir.  A priori un disque dur simple et pas spécialement performant car des accès massivement concurrentiels sur un support quelconque écroule ses perfs. Inutile donc d'investir comme un malade sur du raid haut de gamme / ssd ici.

- destinations imposées : des disques durs SATA, branchés sur une (ou plusieurs. Chaque baie accueille 8 disques destination) baies acceptant les disques sata en hotswap. La baie (ou les baies) est connectée à la station de copie via un lien sas8470 (un ''sata x4'' externe utilisé couramment sur ce type de matos, débit théorique 1200Mo/s).

- la station de copie tourne sous Linux ou Windows. Si copie pyramidale : Windows car plus simple d'utilisation. Si Linux offre un plus, elle tournera sous Linux (d'où mon post). Sous Windows par exemple je suis sûr que le hotswap fonctionne impec car déjà vu tourner ce type de matos, rien vu sous Linux encore. Tu branches ton disque sous Windows, hop il apparait dans le gestionnaire de disques direct y a plus que 3 clics à donner pour le rendre opérationnel.

Maintenant si vous avez des idées de modif dela partie hardware on sait jamais...

Bonne nuit !

sous linux tu insères le disque et il n'y a pas à cliquer. D'ailleurs avec hal/udev la copie peut être immédiate et sans intervention

"peut". Je sais pas le faire et après rapide recherche ça m'a pas l'air simple. Je suis pas une bête de Linux hein...
Windows je peux le faire rapide et surtout pas que moi : au final les utilisateurs seront ''non expérimentés". C'est à dire que le bénéfice doit être tangible si je dois leur taper un script qui prévois tout, simple d'utilisation ect. Parce que ça me prendra du temps à moi donc si au final les perfs sont comparables à Windows, bof
 
Sous Win faudrait dev un truc en langage C ou en tout cas, qui permette d'effectuer des I/O disques à bas niveau. Et ça déjà c'est trop compliqué. Demain je testerai le mode dégueulasse avec des sleep dans le script...

Bien que, autant pour moi udev ça a pas l'air d'être monstrueusement compliqué. Mais bon c'est pas le soucis majeur en fait. Le soucis majeur reste les performances...

ouai bah en fait fallait pas chercher loin ça tient en une commande shell... Commande "wait" juste derrière la boucle.
Marche impec. Merci à tous pour votre aide !

Déjà que tu veux pas regarder tee, c'est pas la peine de se fatiguer à réfléchir à des solutions plus complexes.

Je voudrais pas tirer d'extrapolation psychologique sur les "Linuxiens" mais on dira que de manière générale, on voit une jolie démonstration de la raison pour laquelle Linux est (et restera) un OS pour ''informaticien''.
On perçoit une sorte de compet entre les ''pratiquants'' (certains traits de la communauté Linux l'apparentent à une religion) pour paraître celui ''qui en sait le plus''. Le plus fort, le plus guru. Les réponses typiques sont orientées ''on veut bien t'aider mais faut que tu te prennes la tête aussi''. Le typique ''man dd'' n'est pas sorti mais pas loin... Les admins Linux doivent ressentir la peur ''d'être dépassé'' par des concurrents. D'où une volonté de garder les choses complexes, ralentissant ainsi l'apprentissage des jeunes admins.
 
En DESS à la fac notre prof de système nous a beaucoup décrit (il le faisait avec tristesse, Krakowiac pour les jussieu) ce phénomène.
Le plus curieux c'est que les Français (ensuite ce forum est il représentatif des admins systèmes adeptes Linux Français ???) présentent beaucoup plus ces traits. Toute mon aide a été récupérée grâce aux autre forum. Ici, rien. Voire même des vagues / fausses directions et des tons supérieurs.
 
Pour info j'ai testé le tee ça fonctionne mais extrêmement lent, buffers  I/O trop petits j'imagine (et non paramétrables contrairement à dd). Pour obtenir de bons débits sur les copies de gros fichiers il faut utiliser de grosses I/O (défaut d'un cp/rsync Linux : 64Ko. POur tee je soupçonne ça encore plus petit, cette commande n'ayant je pense pas été pensée pour de la copie de fichiers de 200Go).
 
 
Messieurs les gourous, déjà, à vos cahiers... Et surtout, à votre com... (communication hein, pas commutateur...)

 
On a généralement des réponses du niveau de la question posée. Si il faut t'arracher les informations (où as tu écris que tu avais testé tee ?), ne t'étonnes pas que peu de gens répondent et généralement à côté.
 
Et soyons clair, généraliser comme tu viens de le faire n'a à peu près aucune chance de faire venir les réponses. Par contre, il te fait clairement passer pour quelqu'un de désagréable.