tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

Zakhar · Le 20/05/2011, à 18:56

Alors donc j'ai enlevé la capture d'erreur sur le dd (d'ailleurs c'est pas "propre", s'il y a une erreur, il faudrait que je la traite !) pour voir ce qu'il se passe à cet endroit là :

Et le script "standard" : celui-là qui est standard pour tout le monde.

Tu peux refaire le truc habituel :

bash busyXtremMerge -vf 2.pdf.001.xtm

(l'option f en plus effacera le fichier avant de commencer le recollage, ça t'évite d'avoir à l'effacer "à la main"... mais attention, si tu indiques un fichier important, ça l'écrasera !.. C'est pourquoi ce comportement n'est pas par défaut, au contraire, par défaut on abandonne le recollage si le résultat existe déjà)

Dernière modification par Zakhar (Le 20/05/2011, à 18:58)

stadros83 · Le 20/05/2011, à 19:03

Résultat :

NAS> bash busyXtremMerge -vf 2.pdf.001.xtm
*** VÃ©rification d'existence du premier fichier source...
*** Premier fichier source trouvÃ© : 2.pdf.001.xtm
*** VÃ©rification d'existence du dernier fichier source...
*** Dernier fichier source trouvÃ©: 2.pdf.015.xtm
*** Tailles premier et dernier fichier cohÃ©rentes.
*** DÃ©termination de l'emplacement du rÃ©sultat...
*** Emplacement du rÃ©sultat : TX-SR603_FrEs_0426.pdf
*** VÃ©rification de la possibilitÃ© d'Ã©crire le rÃ©sultat : existence, autorisation d'Ã©criture, espace disponible, etc...
*** 0 fichiers dÃ©jÃ  traitÃ©s.
*** VÃ©rifications pour le fichier rÃ©sultat terminÃ©es.
Traitement optimisÃ© des 15 fichiers
==================================
Traitement de 2.pdf.001.xtm ...  1+0 records in
1+0 records out
BusyBox v1.10.3 (2010-05-17 07:26:08 UTC) multi-call binary

Usage: dd [if=FILE] [of=FILE] [bs=N] [count=N] [skip=N]
        [seek=N]

Copy a file with converting and formatting

Options:
        if=FILE         Read from FILE instead of stdin
        of=FILE         Write to FILE instead of stdout
        bs=N            Read and write N bytes at a time
        count=N         Copy only N input blocks
        skip=N          Skip N input blocks
        seek=N          Skip N output blocks

Numbers may be suffixed by c (x1), w (x2), b (x512), kD (x1000), k (x1024),
MD (x1000000), M (x1048576), GD (x1000000000) or G (x1073741824)

OK
*** grep 85D2DF1F63D3AF9605865820FB082179 6b45e10a0c036e6573a344d5c48a6d95  - = 1
*** Size so far at 1 chunks of 885984 = 0
Traitement de 2.pdf.002.xtm ...  OK
*** grep D14FDD910D99A0C58A405DE5354CDB10 d14fdd910d99a0c58a405de5354cdb10  - = 0
*** Size so far at 2 chunks of 885984 = 885984
Traitement de 2.pdf.003.xtm ...  OK
*** grep CFF35CBA7F82B95C97F9B2E459BFF89E cff35cba7f82b95c97f9b2e459bff89e  - = 0
*** Size so far at 3 chunks of 885984 = 1771968
Traitement de 2.pdf.004.xtm ...  OK
*** grep E1451754B38A1D0082EF7D7A2B8AB5AE e1451754b38a1d0082ef7d7a2b8ab5ae  - = 0
*** Size so far at 4 chunks of 885984 = 2657952
Traitement de 2.pdf.005.xtm ...  OK
*** grep D410544942F7F22EB429DF13A8D114B2 d410544942f7f22eb429df13a8d114b2  - = 0
*** Size so far at 5 chunks of 885984 = 3543936
Traitement de 2.pdf.006.xtm ...  OK
*** grep 9F55B6DE365EBC80EE6174CCCC824B80 9f55b6de365ebc80ee6174cccc824b80  - = 0
*** Size so far at 6 chunks of 885984 = 4429920
Traitement de 2.pdf.007.xtm ...  OK
*** grep 649E4D6194C57D04E1FF49C4370BB47F 649e4d6194c57d04e1ff49c4370bb47f  - = 0
*** Size so far at 7 chunks of 885984 = 5315904
Traitement de 2.pdf.008.xtm ...  OK
*** grep 68840E6F23DFFEC3361AD56B0A8936A1 68840e6f23dffec3361ad56b0a8936a1  - = 0
*** Size so far at 8 chunks of 885984 = 6201888
Traitement de 2.pdf.009.xtm ...  OK
*** grep E93004559C0FA68D4E82079E530F364A e93004559c0fa68d4e82079e530f364a  - = 0
*** Size so far at 9 chunks of 885984 = 7087872
Traitement de 2.pdf.010.xtm ...  OK
*** grep B42E3C1F3DC12AA7974D815C73CDDDF3 b42e3c1f3dc12aa7974d815c73cdddf3  - = 0
*** Size so far at 10 chunks of 885984 = 7973856
Traitement de 2.pdf.011.xtm ...  OK
*** grep 917BF1B1BA39BB3CE5C203B1D7F6E305 917bf1b1ba39bb3ce5c203b1d7f6e305  - = 0
*** Size so far at 11 chunks of 885984 = 8859840
Traitement de 2.pdf.012.xtm ...  OK
*** grep B42230D3DC52F005C113941703950AC2 b42230d3dc52f005c113941703950ac2  - = 0
*** Size so far at 12 chunks of 885984 = 9745824
Traitement de 2.pdf.013.xtm ...  OK
*** grep E0FB6A456ADA074A7CE611A61F8535E0 e0fb6a456ada074a7ce611a61f8535e0  - = 0
*** Size so far at 13 chunks of 885984 = 10631808
Traitement de 2.pdf.014.xtm ...  OK
*** grep 73A34BF1D102A1433A96E63A0BB428F2 73a34bf1d102a1433a96e63a0bb428f2  - = 0
*** Size so far at 14 chunks of 885984 = 11517792
Traitement de 2.pdf.015.xtm ...  BusyBox v1.10.3 (2010-05-17 07:26:08 UTC) multi-call binary

Usage: dd [if=FILE] [of=FILE] [bs=N] [count=N] [skip=N]
        [seek=N]

Copy a file with converting and formatting

Options:
        if=FILE         Read from FILE instead of stdin
        of=FILE         Write to FILE instead of stdout
        bs=N            Read and write N bytes at a time
        count=N         Copy only N input blocks
        skip=N          Skip N input blocks
        seek=N          Skip N output blocks

Numbers may be suffixed by c (x1), w (x2), b (x512), kD (x1000), k (x1024),
MD (x1000000), M (x1048576), GD (x1000000000) or G (x1073741824)

OK
*** grep E1D280FB3250B9B0A9C221747DDFE9F4 d41d8cd98f00b204e9800998ecf8427e  - = 1
*** Size so far at 15 chunks of 885984 = 11517792
==================================================
Toutes les opÃ©rations sont terminÃ©es avec succÃ¨s !
NAS>

Et le fichier produit fait toujours la même taille donc illisible .

Zakhar · Le 20/05/2011, à 19:08

Ok je vois... donc le dd de la busybox n'a que bs et pas ibs/obs !..

C'est pour ça que ça fonctionne avec l'extraction des md5 par exemple, vu que je n'ai besoin que de bs.

Je vais donc aussi surcharger la fonction dd ... le problème c'est que les obs/ibs étaient réglés pour que ça rame pas trop. Enfin bon... on verra !..

Zakhar · Le 20/05/2011, à 19:14

Alors voila... à l'arrache :
Et le script "standard" : celui-là qui est standard pour tout le monde.

Ca devrait être "moche" au niveau de ce qu'il va te raconter mais produire un fichier correct.

Peux-tu le faire avec les "temps" activés que je voie si ça rame pas trop sur le 1 et le 15.

Ca donne ça :

bash busyXtremMerge -vftt 2.pdf.001.xtm

(Option 'tt' -double t- pour avoir tous les temps intermédiaires activés).

Si ça marche je ferai ensuite une version plus "propre" en affichage et test de plantages divers.

... et si les temps intermédiaires prouvent que ça rame démesurément... bah là va falloir se creuser la tête !

Dernière modification par Zakhar (Le 20/05/2011, à 19:20)

stadros83 · Le 20/05/2011, à 19:25

Résultat :

NAS> bash busyXtremMerge -vftt 2.pdf.001.xtm
20:26:00.%N
*** VÃ©rification d'existence du premier fichier source...
*** Premier fichier source trouvÃ© : 2.pdf.001.xtm
*** VÃ©rification d'existence du dernier fichier source...
*** Dernier fichier source trouvÃ©: 2.pdf.015.xtm
*** Tailles premier et dernier fichier cohÃ©rentes.
*** DÃ©termination de l'emplacement du rÃ©sultat...
*** Emplacement du rÃ©sultat : TX-SR603_FrEs_0426.pdf
*** VÃ©rification de la possibilitÃ© d'Ã©crire le rÃ©sultat : existence, autorisation d'Ã©criture, espace disponible, etc...
*** 0 fichiers dÃ©jÃ  traitÃ©s.
*** VÃ©rifications pour le fichier rÃ©sultat terminÃ©es.
20:26:00.%N
Traitement optimisÃ© des 15 fichiers
==================================
Traitement de 2.pdf.001.xtm ...  1+0 records in
1+0 records out
8519+1 records in
8519+1 records out
OK
*** grep 85D2DF1F63D3AF9605865820FB082179 85d2df1f63d3af9605865820fb082179  - = 0
*** Size so far at 1 chunks of 885984 = 885984
20:26:01.%N
Traitement de 2.pdf.002.xtm ...  OK
*** grep D14FDD910D99A0C58A405DE5354CDB10 d14fdd910d99a0c58a405de5354cdb10  - = 0
*** Size so far at 2 chunks of 885984 = 1771968
20:26:01.%N
Traitement de 2.pdf.003.xtm ...  OK
*** grep CFF35CBA7F82B95C97F9B2E459BFF89E cff35cba7f82b95c97f9b2e459bff89e  - = 0
*** Size so far at 3 chunks of 885984 = 2657952
20:26:01.%N
Traitement de 2.pdf.004.xtm ...  OK
*** grep E1451754B38A1D0082EF7D7A2B8AB5AE e1451754b38a1d0082ef7d7a2b8ab5ae  - = 0
*** Size so far at 4 chunks of 885984 = 3543936
20:26:01.%N
Traitement de 2.pdf.005.xtm ...  OK
*** grep D410544942F7F22EB429DF13A8D114B2 d410544942f7f22eb429df13a8d114b2  - = 0
*** Size so far at 5 chunks of 885984 = 4429920
20:26:01.%N
Traitement de 2.pdf.006.xtm ...  OK
*** grep 9F55B6DE365EBC80EE6174CCCC824B80 9f55b6de365ebc80ee6174cccc824b80  - = 0
*** Size so far at 6 chunks of 885984 = 5315904
20:26:01.%N
Traitement de 2.pdf.007.xtm ...  OK
*** grep 649E4D6194C57D04E1FF49C4370BB47F 649e4d6194c57d04e1ff49c4370bb47f  - = 0
*** Size so far at 7 chunks of 885984 = 6201888
20:26:01.%N
Traitement de 2.pdf.008.xtm ...  OK
*** grep 68840E6F23DFFEC3361AD56B0A8936A1 68840e6f23dffec3361ad56b0a8936a1  - = 0
*** Size so far at 8 chunks of 885984 = 7087872
20:26:01.%N
Traitement de 2.pdf.009.xtm ...  OK
*** grep E93004559C0FA68D4E82079E530F364A e93004559c0fa68d4e82079e530f364a  - = 0
*** Size so far at 9 chunks of 885984 = 7973856
20:26:01.%N
Traitement de 2.pdf.010.xtm ...  OK
*** grep B42E3C1F3DC12AA7974D815C73CDDDF3 b42e3c1f3dc12aa7974d815c73cdddf3  - = 0
*** Size so far at 10 chunks of 885984 = 8859840
20:26:01.%N
Traitement de 2.pdf.011.xtm ...  OK
*** grep 917BF1B1BA39BB3CE5C203B1D7F6E305 917bf1b1ba39bb3ce5c203b1d7f6e305  - = 0
*** Size so far at 11 chunks of 885984 = 9745824
20:26:01.%N
Traitement de 2.pdf.012.xtm ...  OK
*** grep B42230D3DC52F005C113941703950AC2 b42230d3dc52f005c113941703950ac2  - = 0
*** Size so far at 12 chunks of 885984 = 10631808
20:26:01.%N
Traitement de 2.pdf.013.xtm ...  OK
*** grep E0FB6A456ADA074A7CE611A61F8535E0 e0fb6a456ada074a7ce611a61f8535e0  - = 0
*** Size so far at 13 chunks of 885984 = 11517792
20:26:01.%N
Traitement de 2.pdf.014.xtm ...  OK
*** grep 73A34BF1D102A1433A96E63A0BB428F2 73a34bf1d102a1433a96e63a0bb428f2  - = 0
*** Size so far at 14 chunks of 885984 = 12403776
20:26:01.%N
Traitement de 2.pdf.015.xtm ...  1+0 records in
1+0 records out
OK
*** grep E1D280FB3250B9B0A9C221747DDFE9F4 e1d280fb3250b9b0a9c221747ddfe9f4  - = 0
*** Size so far at 15 chunks of 885984 = 13289755
20:26:01.%N
==================================================
Toutes les opÃ©rations sont terminÃ©es avec succÃ¨s !
20:26:01.%N
NAS>

Et bingo le fichier est bon !!!!

Zakhar · Le 20/05/2011, à 19:32

Eh oui !.. On y est arrivé.

Bon ben là au niveau des temps on voit pas grand chose parce que :
- les millisecondes ne sont pas affichées (pas de respect du format %N)
- tes fichiers sont "tout petits", moins d'un méga par fichier !..

Mais dans ces conditions là on ne constate aucune différence considérable entre chacun des fichiers, toutes les copies durent un temps infinitésimal puisque l'ensemble se fait en moins d'une seconde.

A l'occasion si tu peux essayer sur un truc plus "gros", du genre des blocs de 1000Méga si tu as ça en stock, ça permettra de voir :
- que ça ne se plante pas quand le bloc à copier pour dd est plus gros.
- que ça ne rame pas trop lamentablement à cause de la "simplification" du dd.

Et en parallèle je fais propre + chrono du nouveau mode de dd sur Ubuntu, pour voir si je peux raisonnablement en faire un truc commun, ou si je dois garder ça que pour BusyBox.

Dernière modification par Zakhar (Le 20/05/2011, à 19:32)

stadros83 · Le 20/05/2011, à 19:32

Et juste pour info, un fichier de plus de 3 Go :

NAS> bash busyXtremMerge -vftt show.mkv.001.xtm
20:27:09.%N
*** VÃ©rification d'existence du premier fichier source...
*** Premier fichier source trouvÃ© : show.mkv.001.xtm
*** VÃ©rification d'existence du dernier fichier source...
*** Dernier fichier source trouvÃ©: show.mkv.004.xtm
*** Tailles premier et dernier fichier cohÃ©rentes.
*** DÃ©termination de l'emplacement du rÃ©sultat...
*** Emplacement du rÃ©sultat : show.mkv
*** VÃ©rification de la possibilitÃ© d'Ã©crire le rÃ©sultat : existence, autorisation d'Ã©criture, espace disponible, etc...
*** 0 fichiers dÃ©jÃ  traitÃ©s.
*** VÃ©rifications pour le fichier rÃ©sultat terminÃ©es.
20:27:09.%N
Traitement optimisÃ© des 4 fichiers
==================================
Traitement de show.mkv.001.xtm ...  1+0 records in
1+0 records out
8977558+1 records in
8977558+1 records out
OK
*** grep 0D1092CED18CF6001076215ECB0FCD82 0d1092ced18cf6001076215ecb0fcd82  - = 0
ls: /volume1/DATA/Incoming/Torrent/1/[WoM-F]: No such file or directory
*** Size so far at 1 chunks of 933666097 =
20:27:58.%N
Traitement de show.mkv.002.xtm ...  OK
*** grep 3FE5AA0F91B7D0804CAAAAACCB0A16AC 3fe5aa0f91b7d0804caaaaaccb0a16ac  - = 0
ls: /volume1/DATA/Incoming/Torrent/1/[WoM-F]: No such file or directory
*** Size so far at 2 chunks of 933666097 =
20:28:26.%N
Traitement de show.mkv.003.xtm ...  OK
*** grep BD131092B68126D3DE927DD0A8F7E908 bd131092b68126d3de927dd0a8f7e908  - = 0
ls: /volume1/DATA/Incoming/Torrent/1/[WoM-F]: No such file or directory
*** Size so far at 3 chunks of 933666097 =
20:28:53.%N
Traitement de show.mkv.004.xtm ...  1+0 records in
1+0 records out
OK
*** grep 938B6FFDA7633092A06E97400D7FC04C 938b6ffda7633092a06e97400d7fc04c  - = 0
ls: /volume1/DATA/Incoming/Torrent/1/[WoM-F]: No such file or directory
*** Size so far at 4 chunks of 933666097 =
20:30:04.%N
==================================================
Toutes les opÃ©rations sont terminÃ©es avec succÃ¨s !
20:30:04.%N
NAS>

Dernière modification par stadros83 (Le 20/05/2011, à 19:33)

Zakhar · Le 20/05/2011, à 19:39

Impec tu l'as fait en parallèle que je le demandais...
1er bloc = 49sec
2ème bloc = 28 sec
3ème bloc = 27 sec
Dernier = 11 sec (mais on connait pas sa taille parce que le nom du fichier résultat étant bizarre... le prog le trouve pas !)

Donc sur le premier ça rame un peu tout en restant "raisonnable" (deux fois moins vite que les autres). Mais vu que le dd de la busybox n'a pas ibs/obs, je vais pas pouvoir faire mieux.

Par contre ça m'oblige à faire "malin" parce que je vais pas dégrader les temps ainsi pour les versions "Linux" normales.

Merci donc pour tous tes tests, et je reposte quand j'ai fait un truc "définitif" (enfin je veux dire là c'était des versions de développement avec plein de messages de debug !)

stadros83 · Le 20/05/2011, à 20:09

En tout cas un grand merci !

Zakhar · Le 20/05/2011, à 20:45

Et j'ai même une petite idée pour améliorer la performance...

Là on fait :
dd 104 x 1 (pour l'entête)
dd 104 x N en sautant le 1er 104 (jusqu'à la fin du fichier)

Et c'est le 2ème qui rame, parce que lire un fichier de 1G à coup de 104 octets... ça fait presque 10 millions de petits blocs qui en plus ne sont même pas alignés aux structures des disques !..
Donc je vais faire pour les Busybox
dd 104 x 1 (pour l'entête)
dd 8 x 499 en sautant 13 x 8 (soit saut de 13 x 8 = 104, et lecture de 499 x 8 = 3992, total lu : 104+ 3992 = 4096)
dd 4096 x N en sautant 1er 4096 (4096 est la taille standard des blocs des filesystem Linux)

On se ramène alors à 250K (+500) lectures avec des tailles de blocs compatibles avec les filesystems standards.
Malgré le 3ème dd, ça devrait ramener la lecture aux alentours de la performance sur les Linux standard.

Je fais les chronos tout à l'heure !

Dernière modification par Zakhar (Le 20/05/2011, à 20:45)

Zakhar · Le 21/05/2011, à 09:40

Bonjour stadros83,

voici donc la version "bêta" toute propre et sensée marcher sur Synology DS1010+ :
Le script spécial : celui-là spécial pour Busybox.
Et le script "standard" : celui-là qui est standard pour tout le monde.

On passe en 1.0.0 pour le "spécial" et en 1.6.0 pour le standard.

Peux-tu les télécharger sur ton Synology et refaire le test avec le "gros" fichier, afin de vérifier que je n'ai rien cassé en "faisant le ménage" !..

Donc :

bash busyXtremMerge -vftt show.mkv.001.xtm

et me mettre le résultat.

J'ai utilisé l'algorithme mentionné au post #110 dans la partie commune du script. Ca fait une commande de plus, mais on gagne du temps même sur Linux standard (7% environ). Le gain de temps sur le premier fichier pour Synology devrait être beaucoup plus conséquent, de l'ordre de 40%.
Ton test permettra de vérifier tout ça en plus du fonctionnement normal.

Une fois ta confirmation reçue, je mettrai le script testé sur la page 1 dans sa nouvelle version, à disposition de tout le monde.
Je rajouterai aussi quelques mots d'explication pour Synology.

Concernant le Busybox version antérieure, à part qu'il est une version antérieure justement, as-tu constaté d'autre régressions sur les fonctions standard de ton NAS (ils sont un peu crétins de mettre à disposition des "régressions"... je me demande bien à quoi ça sert !)

P.S.: le "bug de documentation" sur od, que j'ai signalé aux mainteneurs d'Ubuntu, est confirmé. Précisément, c'est un bug de traduction qui existe sur la version française (en anglais c'est OK). Je vais voir si c'est pas trop "prise de tête" d'en parler aussi chez Busybox... je me demande s'ils ont pris la doc sur la version Française... ou si d'autres langues ont aussi le problème !

Dernière modification par Zakhar (Le 21/05/2011, à 09:44)

Zakhar · Le 21/05/2011, à 10:18

Voila, bug du 'od' signalé aussi chez Busybox

stadros83 · Le 21/05/2011, à 12:58

Je me suis encore servi du script ce matin !

Ca fonctionne impec .

Zakhar · Le 21/05/2011, à 13:01

Super !

Il s'agit du nouveau ? (le 1.0.0 / 1.6.0)

Et peux-tu me faire le test demandé (post 111) que je voies par comparaison si le changement d'algorithme a été efficace ou si je dois encore creuser ?

stadros83 · Le 21/05/2011, à 13:32

Je n'avais pas vu les nouveaux scripts !

Voici les résultats :

NAS> bash busyXtremMerge -vftt show.mkv.001.xtm
14:30:12.%N
*** VÃ©rification d'existence du premier fichier source...
*** Premier fichier source trouvÃ© : show.mkv.001.xtm
*** VÃ©rification d'existence du dernier fichier source...
*** Dernier fichier source trouvÃ©: show.mkv.004.xtm
*** Tailles premier et dernier fichier cohÃ©rentes.
*** DÃ©termination de l'emplacement du rÃ©sultat...
*** Emplacement du rÃ©sultat : [WoM-F] Bienvenue au show spatial HD.mkv
*** VÃ©rification de la possibilitÃ© d'Ã©crire le rÃ©sultat : existence, autoris                                                                                                                     ation d'Ã©criture, espace disponible, etc...
*** 0 fichiers dÃ©jÃ  traitÃ©s.
*** VÃ©rifications pour le fichier rÃ©sultat terminÃ©es.
14:30:12.%N
Traitement optimisÃ© des 4 fichiers
==================================
Traitement de show.mkv.001.xtm ...  OK
14:30:40.%N
Traitement de show.mkv.002.xtm ...  OK
14:31:04.%N
Traitement de show.mkv.003.xtm ...  OK
14:31:31.%N
Traitement de show.mkv.004.xtm ...  OK
14:32:29.%N
==================================================
Toutes les opÃ©rations sont terminÃ©es avec succÃ¨s !
14:32:29.%N
NAS>

Soit environ 50secondes de gagnées à priori, pas mal du tout !

Pour ce qui est du Busybox, ce n'est pas Synology qui l'a mis à disposition, c'est ma faute, j'ai installé ipkg pour pouvoir installer d'autres logiciels sur mon NAS, mais le busybox dispo dessus n'était pas à jour.
Par contre ce qui est étonnant c'est qu'il se soit mis à jour malgré le fait que la version était antérieure ?!

Zakhar · Le 21/05/2011, à 13:42

Oui c'est mieux !

Le premier fichier met désormais un temps "normal" par rapport aux autres :
Fichier 1 = 28 sec
Fichier 2 = 24 sec
Fichier 3 = 27 sec
Fichier 4 = 58 sec

... c'est juste le temps du Fichier 4 qui est bizarre... pourtant sur ce point je n'ai rien changé par rapport à ce que tu avais testé. On va mettre ça sur le compte du fait que tu as peut-être fait autre chose en parallèle, sur la bufferisation (Linux fait plein de choses en parallèle) ou d'autre choses étranges.

En l'occurrence je vois aussi que le résultat est "propre" (sauf l'UTF-8 qui n'est pas respecté, les lettres accentuées ressortant mal, mais c'est pas dramatique).

On va donc déclarer cette version "bonne pour le service".

Et merci à toi pour ta patience et tous les tests.
N'hésite pas si tu rencontres d'autres bugs sur le script dans des cas particuliers (sauf les .exe en xtm... ça le script ne le fait pas car le format n'est pas public).

stadros83 · Le 21/05/2011, à 13:45

Merci à toi pour le temps consacré surtout !!

C'est beaucoup plus rapide pour recoller que de passer par le réseau !

Zakhar · Le 21/05/2011, à 13:46

stadros83 a écrit :

C'est beaucoup plus rapide pour recoller que de passer par le réseau !

Sûr, c'est un des intérêts de cette façon de faire (le script) !.. Et d'autant plus si tu as un réseau à 100Mbps

J'en sais quelque chose, auparavant mon PC portable était en 100Mbps, lorsque je copiais de trucs genre "Film DVD" (sans parler des HD !) je le sentais passer...

L'autre avantage est l'optimisation. Avec le truc Windows, tu fais :
- Lecture du fichier (disque NAS)
- Transfert réseau
- Calcul du MD5 (sur PC)
- (re) Lecture du fichier (disque NAS)
- Transfert réseau (NAS vers PC pour la lecture)
- Transfert réseau (PC vers NAS pour l'écriture)
- Ecriture du fichier (disque NAS)

Avec mon script optimisé tu fais
- Lecture du fichier (disque NAS)
- Ecriture du fichier (disque NAS) & Calcul des MD5 (processeur NAS) en parallèle

alors sûr... ya pas photo !..
Tu économises tout le temps des 3 transferts plus de la deuxième lecture, et le calcul du MD5 se fait en parallèle de l'écriture, il est donc "gommé".

Aussi, la puissance de calcul (MD5, copies/transferts) est à 100% sur le NAS, ce qui permet de faire autre chose en parallèle sur le PC.

Conclusion, si je corrige le temps du Fichier 4 ci-dessus avec le temps de ta première mesure, ça donne :
busyXtremMerge = 90 sec
XtremSplit (Windows) = 252 sec (hypothèse Gigabit Ethernet)
Détail des temps rajoutés :
- Réseau = 37,5 x 3 = 112,5 sec [80Mbps] (*)
- Lecture supplémentaire = 40 sec [80Mbps]
- MD5 calculé en série = 10 sec [300Mbps => dépend de ton processeur sur le PC]

Soit un temps de 252 sec... presque 3 fois plus qu'avec le script.

(*) Avec un réseau à 100Mbps, il faut plutôt compter environ 15 min pour les 3 transferts... ce qui pour le coup devient effectivement assez ridiculement élevé par rapport au script !.. Mais pour cette raison, avoir un NAS en étant à 100Mbps est une assez mauvaise configuration... et j'ai donc supposé le Gigabit Ethernet

P.S.: pour être honnête il faut retirer une 10aine de seconde qui est l'écart de temps qu'il te faut entre taper la commande et cliquer sur un truc graphique... mais avec l'habitude, et avec les commandes mémorisées automatiquement... ça finit même par devenir plus rapide en ligne de commande, foi de Linuxien !

Dernière modification par Zakhar (Le 21/05/2011, à 15:26)

stadros83 · Le 21/05/2011, à 15:50

J'ai du gigabit mais il ne faut pas se leurrer, difficile de dépasser les 50 Mo/s avec du matériel pour les particuliers .

Zakhar · Le 21/05/2011, à 15:53

Surtout avec Windows qui ne sait faire que du Samba.

Moi, entre mon PC de bureau et mon PC portable, j'arrive à tourner à plus de 80Mbps, en fait, ce qui bloque, à ce niveau là, c'est la vitesse du disque dur !..
Mais bon, c'est sûr je fais ça en NFS (le protocole standard Linux) et c'est bien plus performant que SMB/Samba.

Malheureusement pour les Windowsiens, c'est pas disponible (ou pas simplement et pas aussi performant) pour Windows !...

Tu sais, c'est un peu comme la Freebox V6 :
- Samba <10Mbps
- FTP 20Mbps (40 en lecture)

A la limite, si tu as de gros transferts à faire sur le disque de ton PC (on fait moins ça avec un NAS) essaye le FTP, ça peut améliorer, car Samba... humm... ouais bof quoi !

Dernière modification par Zakhar (Le 21/05/2011, à 15:56)

stadros83 · Le 21/05/2011, à 16:01

Je suis en CIFS .

Donc normalement bien mieux que le SMB niveau vitesse.

Mais bon perso ça me suffit, surtout que 99% du temps je suis en wifi !

Zakhar · Le 21/05/2011, à 16:06

Bah non, CIFS c'est Samba/SMB

Regarde là

Et sûr, en Wifi ça a encore moins d'importance parce que là ça rame encore plus à cause de la Wifi

stadros83 · Le 21/05/2011, à 16:13

Ah je pensais qu'il y avait quand même des différences .

Zakhar · Le 21/05/2011, à 16:47

Oui, il y a des différences : le nom est pas le même.

Sont trop forts chez Microsoft pour vendre la même soupe avec plein de noms différents !..

Zakhar · Le 21/05/2011, à 16:54

21 mai 2011
Version 1.6.0

Crédit à stadros83 pour son patient debug (3 pages de posts !) sur Synology DS1010+
Modification de l'algorithme pour le premier fichier afin de le rendre compatible Busybox
(pas de ibs/obs sur le dd). Ainsi modifié, c'est également plus rapide sur Linux standard !
Simplification algo sur le dernier fichier (idem ci-dessus).
Rajout de l'option pipefail pour ne pas "masquer" les éventuelles erreurs lors des "pipes" du processus de recollage.

Version 1.5.6

Remplacement de od par dd lorsqu'on doit lire des chaines.
Remplacement de basemane par interne ${var##*/}

Création du "script compagnon" busyXtremMerge contenant les adaptations pour Busybox
Version 1.0.0

Nouveaux algorithmes (main script) pour les dd sans ibs/obs
Contournement pour l'inexistence du "process substitution"
Remplacement du stat -c%s par une fonction (ls + tr + cut)
Suppression 'du' (main script - homogénéisation)

Version 0.9.0

readlink ne se comporte pas pareil sur Synology 1010+
Retrait de readlink, remplacé par la fonction shell readlnk

Dernière modification par Zakhar (Le 21/05/2011, à 16:55)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#101 Le 20/05/2011, à 18:56

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#102 Le 20/05/2011, à 19:03

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#103 Le 20/05/2011, à 19:08

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#104 Le 20/05/2011, à 19:14

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#105 Le 20/05/2011, à 19:25

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#106 Le 20/05/2011, à 19:32

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#107 Le 20/05/2011, à 19:32

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#108 Le 20/05/2011, à 19:39

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#109 Le 20/05/2011, à 20:09

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#110 Le 20/05/2011, à 20:45

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#111 Le 21/05/2011, à 09:40

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#112 Le 21/05/2011, à 10:18

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#113 Le 21/05/2011, à 12:58

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#114 Le 21/05/2011, à 13:01

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#115 Le 21/05/2011, à 13:32

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#116 Le 21/05/2011, à 13:42

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#117 Le 21/05/2011, à 13:45

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#118 Le 21/05/2011, à 13:46

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#119 Le 21/05/2011, à 15:50

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#120 Le 21/05/2011, à 15:53

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#121 Le 21/05/2011, à 16:01

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#122 Le 21/05/2011, à 16:06

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#123 Le 21/05/2011, à 16:13

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#124 Le 21/05/2011, à 16:47

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#125 Le 21/05/2011, à 16:54

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

Pied de page des forums