En fait, pour mieux comprendre le pourquoi, il faut comprendre le besoin :
T'a des To de fichiers (qq Mo à 100 Go) étalés dans des stockages hétérogènes, dans des stations de travail spécialisées, dans des vieux stockages, dans des SAN/NAS à protocoles et clients proprios.
Tu doit bricoler des montages de montages, rebondir de machines en machines. Via des vieux linux, des vieux macs.
Et le but c'est de tout réunir pour l'envoyer dans un stockage "sur" qui est parfois le sas d'entrée vers un système d'archive vers LTO.
Et la copie est lancée, t'a 150000 fichiers, la copie va prendre une 30aine d'heures. Tu voudrait enlever certains types de fichiers, et donc tu voudrait faire un tri préalable avant de tout lancer. Et parfois la copie rate en cours. Un montage saute. Les perfs s'effondrent. Pire, un file system saute et bloque net le transfert. Obligé de reboot.
Et tu ne veux pas tout recommencer, le scan, le tri, les copies, etc...
Le calcul du débit moyen et instantané pour détecter les pb avec le FS, c'est redoutable quand il que dit que tu fait du 2 MB/sec en moyenne et du 100 MB/sec en instantané.
ExtendCopy est fait pour cela. Surtout pour cela.
Ensuite, ce n'est peut-être pas clair, mais il calcul un MD5 (ou autre) pendant la copie, le note, et il y a une fonction qui fait un replay sur les fichiers copiés et qui vérifie les mesures.
Le fichier produit en sorti (un txt tabulé) est la preuve de ce qui a été copié, et que c'est bien copié. Quand on parle client/fournisseur/prestation/assurance/facturation, c'est important.
J'ai fait ce dev car... j'ai rien trouvé pour faire cela facilement. Les scripts bash, c'est bien quand t'est chez toi a ton bureau, c'est chaud quand t'est en clientèle, dans leur nodal, à 4 pattes par terre devant le seul écran trouvé, le nez sur un XSAN bardé de bad-blocs.
[^] # Re: choix d'architecture logiciel
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal Évolution et maturation de MyDMAM. Évalué à 3.
En fait, pour mieux comprendre le pourquoi, il faut comprendre le besoin :
T'a des To de fichiers (qq Mo à 100 Go) étalés dans des stockages hétérogènes, dans des stations de travail spécialisées, dans des vieux stockages, dans des SAN/NAS à protocoles et clients proprios.
Tu doit bricoler des montages de montages, rebondir de machines en machines. Via des vieux linux, des vieux macs.
Et le but c'est de tout réunir pour l'envoyer dans un stockage "sur" qui est parfois le sas d'entrée vers un système d'archive vers LTO.
Et la copie est lancée, t'a 150000 fichiers, la copie va prendre une 30aine d'heures. Tu voudrait enlever certains types de fichiers, et donc tu voudrait faire un tri préalable avant de tout lancer. Et parfois la copie rate en cours. Un montage saute. Les perfs s'effondrent. Pire, un file system saute et bloque net le transfert. Obligé de reboot.
Et tu ne veux pas tout recommencer, le scan, le tri, les copies, etc...
Le calcul du débit moyen et instantané pour détecter les pb avec le FS, c'est redoutable quand il que dit que tu fait du 2 MB/sec en moyenne et du 100 MB/sec en instantané.
ExtendCopy est fait pour cela. Surtout pour cela.
Ensuite, ce n'est peut-être pas clair, mais il calcul un MD5 (ou autre) pendant la copie, le note, et il y a une fonction qui fait un replay sur les fichiers copiés et qui vérifie les mesures.
Le fichier produit en sorti (un txt tabulé) est la preuve de ce qui a été copié, et que c'est bien copié. Quand on parle client/fournisseur/prestation/assurance/facturation, c'est important.
J'ai fait ce dev car... j'ai rien trouvé pour faire cela facilement. Les scripts bash, c'est bien quand t'est chez toi a ton bureau, c'est chaud quand t'est en clientèle, dans leur nodal, à 4 pattes par terre devant le seul écran trouvé, le nez sur un XSAN bardé de bad-blocs.