[Opengnsys-users] Errores con ctorrent al acabar la descarga

Miguel Sánchez Sánchez msanchez en fi.upm.es
Lun Jul 12 14:36:37 CEST 2021


Gracias, Pep. Más sencillo todavía que mi script y vale para todo pues 
para cada aula sólo servirás el pequeño número de imágenes que se 
utilicen en ella.

Saludos.

Pep Ciuraneta Sanchez escribió el 12/7/21 a las 14:20:
> Para lanzar el ctorrent como seeder hemos hecho un procedimiento que 
> se compone de un único shell script, ahora modificado gracias a ti, 
> muy similar al contenido del rc.local:
>
>
> Código script:*
> #!/bin/bash
>
> cd /opt/opengnsys/cache/opt/opengnsys/images/
> for i in `/bin/ls /opt/opengnsys/cache/opt/opengnsys/images/*.torrent`; do /usr/bin/ctorrent -e -1 -f -d $i; done
>
> exit 0
> * 
> <https://147.83.79.251/opengnsys/varios/informacion_acciones.php?idtipoaccion=68&descripcionaccion=ACTIVAR%20TORRENT&tipoaccion=33#nodo> 
>
>
>
> de manera que cuando necesito tener mas seeders los puedo ir añadiendo 
> encendiendo equipos en modo OGClient y ejecutándoles el procedimiento. 
> Así, como ejemplo de despliegue de una imagen nueva lo que podemos 
> hacer es hacer el deploy en un aula pequeña pero rápida y una vez han 
> acabado, ejecutar el procedimiento en ese ámbito, incrementando el 
> número de seeders de forma sencilla para seguir haciendo el deploy en 
> el resto de aulas.
>
> Sobre el segundo punto, tomo nota por si se nos reproduciera mucho el 
> error para parchear el ctorrent. De momento desde el cambio del 
> bittornado por el ctorrent creo que solo nos han petado 3 descargas de 
> un total de varios centenares por lo que no nos preocupa en absoluto. 
> Una cosa que creo que seria bastante positiva si no fuera costosa 
> seria incorporar ese ctorrent parcheado a los OGLive del proyecto.
>
> Saludos y gracias,
> Pep.
> -- 
> O O O Universitat Politecnica de Catalunya
> O O O BarcelonaTECH
> O O O ------------------------------------
> U P C Facultat de Matematiques i Estadistica
>        Pau Gargallo, 14 - 08028 Barcelona
>
>        Pep Ciuraneta Sanchez
>        Serveis TIC
>        josep.ciuraneta en upc.edu  <mailto:josep.ciuraneta en upc.edu>
>        Tel. 934015853
>
> AVIS DE CONFIDENCIALITAT:
> Aquest missatge pot contenir informacio confidencial o legalment protegida i esta exclusivament adrecat a la persona o entitat destinataria. Si no sou el destinatari final o persona encarregada de recollir-lo, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar el seu contingut. Si heu rebut aquest missatge per error, us preguem que informeu al remitent i elimineu del vostre sistema el missatge i el material annex que pugui contenir. Gracies per la vostra col.laboracio.
>
> Abans d'imprimir aquest correu, penseu si es necessari.
>
>
> Missatge de Miguel Sánchez Sánchez <msanchez en fi.upm.es 
> <mailto:msanchez en fi.upm.es>> del dia dl., 12 de jul. 2021 a les 12:39:
>
>     Hola Pep. Comento entre líneas.
>
>     Pep Ciuraneta Sanchez escribió el 12/7/21 a las 12:18:
>>     Hola Miguel,
>>
>>     Gracias por indicarme la opcion -f del ctorrent. Lo acabo de
>>     añadir en todos los scripts. :)
>>
>>     No entiendo lo que comentas sobre el asistente de deploy de
>>     imagenes. Yo lo he estado usando en las pruebas y funciona
>>     perfecto. Quiza no estamos hablando de lo mismo.
>     Me refería a lanzar el semillero desde un ogLive. Aunque ahora
>     mismo tampoco estoy seguro de que el engine de las librerías del
>     ogLive no detecte la imagen en caché adecuadamente y no tenga que
>     volver a descargarse la imagen en concreto cuando lanzas los
>     semilleros desde el asistente.
>>
>>     Sobre los errores del ctorrent por entrar en modo EndGame no nos
>>     ha pasado en multiples pruebas de descarga. Unicamente se me han
>>     producido algun error, minimo, al inicio de la descarga, que
>>     supongo debe ser el otro que comentas, con parche existente.
>     Sí, me refería a ese error inicial. Yo incorporé el parche y en
>     las pruebas no volvió a surgir el error de segmentation fault. En
>     nuestro caso, tampoco era desdeñable el porcentaje de equipos que
>     fallaban con ese error.
>     Pero dependía mucho de la situación de inició de la descarga. Me
>     explico, el semillero de Bittornado o Bittorrent se conecta al
>     tracker por defecto cada 5 minutos (parámetro rerequest_interval)
>     para anunciarse y volver a aparecer en él. Si los clientes esperan
>     varios minutos porque el semillero no aparece en el tracker,
>     inician la descarga al unísono cuando llega a aparece y ante la
>     llamada al modo endgame (o initial, no sé) inicial, un porcentaje
>     de ellos (hasta cerca de la mitad en algún caso) falla. Se puede
>     reducir la incidencia bajando el intervalo del parámetro.
>     En tu caso, que utilizas como semillero a ctorrent, supongo que no
>     es tan común.
>>
>>     Gracias de nuevo y si quieres que probemos algo solo tienes que
>>     decirlo.
>     Igualmente, Pep.
>>
>>     Saludos,
>>     Pep.
>>     -- 
>>     O O O Universitat Politecnica de Catalunya
>>     O O O BarcelonaTECH
>>     O O O ------------------------------------
>>     U P C Facultat de Matematiques i Estadistica
>>            Pau Gargallo, 14 - 08028 Barcelona
>>
>>            Pep Ciuraneta Sanchez
>>            Serveis TIC
>>            josep.ciuraneta en upc.edu  <mailto:josep.ciuraneta en upc.edu>
>>            Tel. 934015853
>>
>>     AVIS DE CONFIDENCIALITAT:
>>     Aquest missatge pot contenir informacio confidencial o legalment protegida i esta exclusivament adrecat a la persona o entitat destinataria. Si no sou el destinatari final o persona encarregada de recollir-lo, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar el seu contingut. Si heu rebut aquest missatge per error, us preguem que informeu al remitent i elimineu del vostre sistema el missatge i el material annex que pugui contenir. Gracies per la vostra col.laboracio.
>>
>>     Abans d'imprimir aquest correu, penseu si es necessari.
>>
>>
>>     Missatge de Miguel Sánchez Sánchez <msanchez en fi.upm.es
>>     <mailto:msanchez en fi.upm.es>> del dia dl., 12 de jul. 2021 a les
>>     10:26:
>>
>>         Hola Pep. Sí, la verdad es que los problemas de segmentation
>>         fault nos empezaron a surgir ya en la versión 1.0.6 y
>>         entonces optamos por la solución que tú comentas. Por cierto,
>>         la función ogTorrentStart lanza ctorrent con la opción -f.
>>         Creía que era para evitar el chequeo inicial de la imagen.
>>         La verdad es que optimiza el uso de la red al máximo, pero
>>         tiene la pega de no poder utilizar el asistente de deploy de
>>         imágenes.
>>         Aunque el despliegue de semilleros que utilizamos en su día
>>         era sencillo, utilizando algunos ogLIve como la imagen ya en
>>         la caché:
>>         IMG=<fichero de imagen>
>>         IMGDIR=$(ogGetParentPath CACHE /$IMG)
>>         ogCopyFile REPO $IMG.torrent $IMGDIR
>>         ogTorrentStart CACHE $IMG.torrent seeder:<tiempo en segundos>
>>
>>         En cuanto a los problemas de segmentation fault y abortos de
>>         ctorrent, después de ponerlo en debug, he podido ver que en
>>         ambos casos están relacionados con la entrada en el modo
>>         EndGame de BitTorrent. Ese modo se utiliza sobre todo al
>>         finalizar las descargas, preguntando a todos los peers por
>>         las partes que le faltan a un cliente, y cancelando las
>>         respuestas a peticiones repetidas. Lamentablemente, ctorrent
>>         no gestiona bien esas cancelaciones y termina cometiendo
>>         errores como la creación de arrays de longitud negativa.
>>         Para el problema del segmentation fault, que se da al poco de
>>         comenzar las sesiones de descarga, creo que tienen un
>>         sencillo parche en
>>         https://sourceforge.net/p/dtorrent/patches/6/ que lo solventa.
>>         Pero solucionar el bug del error final
>>         std::bad_array_new_length creo que me supera, por lo que he
>>         optado por el camino de en medio, evitando que ctorrent entre
>>         en modo endgame. Tiene el inconveniente de que la
>>         localización de las partes finales de una descarga tardan
>>         algo más.
>>         Lo curioso de este último error es que sólo se da, como
>>         comentaba, si los clientes llegan parejos al final en las
>>         partes descargadas. Este sólo es el caso cuando la velocidad
>>         para servir disco del semillero es menor que la velocidad de
>>         la red, de tal manera que los clientes terminan convergiendo
>>         entre ellos aunque arranquen después de un tiempo aleatorio
>>
>>         Tras regenerar el paquete deb de ctorrent luego sólo hay que
>>         instalarlo en el sistema de ficheros squashfs de
>>         ogclient.sqfs, para que luego lo cargue el ogLive.
>>
>>         Bueno, al final creo me ha salido también otro ladrillo.
>>         Saludos.
>>
>>         Pep Ciuraneta Sanchez escribió el 9/7/21 a las 18:21:
>>>         Hola Miguel,
>>>
>>>         Te explico, nosotros empezamos haciendo pruebas con 1.2.0
>>>         para ver si solucionabamos unos problemas con el torrent (no
>>>         aprovechamiento del ancho de banda, falta de fiabilidad con
>>>         muchos errores segmentation fault en clientes) y al ver que
>>>         con 1.2.0 nos pasaba lo mismo hemos cambiado el programa que
>>>         se encarga de hacer el seed. Seguimos con 1.1.0 de momento.
>>>         Esto lo hemos hecho tras hacer pruebas esta misma semana.
>>>
>>>         En lugar de usar el bittornado hemos optado por lanzar un
>>>         ctorrent por cada fichero torrent. Esto tiene su
>>>         inconveniente, pero desde entonces el ancho de banda se
>>>         aprovecha algo mejor y los errores se han minimizado
>>>         muchísimo. De momento lo vamos a dejar así. En concreto lo
>>>         lanzamos así para cada fichero (simplificado)
>>>
>>>         # cd /opt/opengnsys/images
>>>         # ctorrent -e -1 -d nombre_fichero_img.torrent
>>>
>>>         Yo creo que esto es extrapolable a la versión 1.2.0. El
>>>         hecho de usar ctorrent en lugar de bittornado funciona
>>>         bastante mejor, pero tiene la pega que cada vez que se
>>>         inicia se comprueba el fichero a compartir y eso puede ser
>>>         costoso en tiempo y depende de la velocidad acceso de disco.
>>>
>>>         Hemos aprovechado este final de curso para hacer multiples
>>>         pruebas y el poder aprovechar la red a 1Gbps da bastante
>>>         alegria.
>>>
>>>         Consejos para subir la velocidad en descarga por torrent:
>>>
>>>         1.- si es posible, tener los ficheros imagen en disco SSD
>>>         2.- tener algun seeder extra. No hace falta que sea un REPO,
>>>         simplemente una máquina de backup donde tener los ficheros
>>>         imagen y los torrent.
>>>         3.- si los equipos destino tienen disco SSD comprobar que
>>>         las particiones esten alineadas. Esto es muy importante.
>>>         4.- Realizar un procedimiento para hacer que las aulas o
>>>         equipos que tengan la imagen puedan hacer de seeders.
>>>         Basicamente es lanzar un ctorrent y esperar al chequeo de
>>>         cada imagen, pero esto ayuda mucho a subir la velocidad de
>>>         descarga. Esto equivale a multiplicar el consejo 2 por el
>>>         numero de máquinas en las que se ejecute el procedimiento.
>>>         Por ejemplo, se puede descargar primero en el aula donde sea
>>>         más rapido el despliegue y luego añadir sus equipos como
>>>         seeders para acelerar al resto.
>>>         5.- Tener REPOS repartidos por diferentes tramos de la red.
>>>         Esto depende de la infraestructura de cada uno.
>>>
>>>         Miguel, Perdona el ladrillo, al final me ha salido algo
>>>         largo. En resumen, prueba de cambiar el bittornado por un
>>>         script que te lance los ctorrent (en el mismo rc.local) y a
>>>         ver que tal.
>>>
>>>         Saludos,
>>>         Pep.
>>>         -- 
>>>         O O O Universitat Politecnica de Catalunya
>>>         O O O BarcelonaTECH
>>>         O O O ------------------------------------
>>>         U P C Facultat de Matematiques i Estadistica
>>>                Pau Gargallo, 14 - 08028 Barcelona
>>>
>>>                Pep Ciuraneta Sanchez
>>>                Serveis TIC
>>>                josep.ciuraneta en upc.edu  <mailto:josep.ciuraneta en upc.edu>
>>>                Tel. 934015853
>>>
>>>         AVIS DE CONFIDENCIALITAT:
>>>         Aquest missatge pot contenir informacio confidencial o legalment protegida i esta exclusivament adrecat a la persona o entitat destinataria. Si no sou el destinatari final o persona encarregada de recollir-lo, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar el seu contingut. Si heu rebut aquest missatge per error, us preguem que informeu al remitent i elimineu del vostre sistema el missatge i el material annex que pugui contenir. Gracies per la vostra col.laboracio.
>>>
>>>         Abans d'imprimir aquest correu, penseu si es necessari.
>>>
>>>
>>>         Missatge de Miguel Sánchez Sánchez <msanchez en fi.upm.es
>>>         <mailto:msanchez en fi.upm.es>> del dia dv., 9 de jul. 2021 a
>>>         les 12:39:
>>>
>>>             Buenas. Me estoy encontrando con que un porcentaje de
>>>             ogLive, cuando van
>>>             a acabar la descarga de una imagen, ctorrent aborta con
>>>             error
>>>             std::bad_array_new_length.
>>>             Todos los clientes torrent van más o menos igual en la
>>>             descarga, pues
>>>             acaban bien o fallan al alimón, pues el semillero en el
>>>             servidor parece
>>>             que no supera los 50Mbit por conexión, y aunque empiezan
>>>             la descarga
>>>             aleatoriamente van convergiendo. Abortan con un número
>>>             pequeño de partes
>>>             por completar, menos de 20.
>>>
>>>             No estoy seguro si está relacionado con algún parámetro
>>>             del semillero en
>>>             el servidor, pues hasta ahora nuestro servidor de
>>>             OpenGnsys estaba un
>>>             poco escaso de recursos y el problema parece que
>>>             desaparecía cuando se
>>>             limitaban en el semillero el número de peers que se
>>>             podían conectar.
>>>             Pero hemos cambiado a versión 1.2.0 en un nuevo servidor
>>>             y el problema
>>>             persiste.
>>>             El semillero que estamos utilizando actualmente es
>>>             btlaunchmany.bittorrent, por aquello de que utiliza un
>>>             thread por imagen
>>>             servida. Pero creo recordar que con
>>>             btlaunchmany.bittornado los errores
>>>             también se producían.
>>>
>>>             ¿Os habéis encontrado alguno con este problema? ¿Cómo lo
>>>             habéis solventado?
>>>
>>>             Saludos.
>>>             _______________________________________________
>>>             Opengnsys-users mailing list
>>>             Opengnsys-users en listas.unizar.es
>>>             <mailto:Opengnsys-users en listas.unizar.es>
>>>             https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
>>>             ----------
>>>             INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>>>
>>>             Ud. recibe este correo por pertenecer a una lista de
>>>             correo gestionada por la Universidad de Zaragoza.
>>>             Puede encontrar toda la información sobre como tratamos
>>>             sus datos en el siguiente enlace:
>>>             https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
>>>             Recuerde que si está suscrito a una lista voluntaria Ud.
>>>             puede darse de baja desde la propia aplicación en el
>>>             momento en que lo desee.
>>>             http://listas.unizar.es
>>>             ----------
>>>
>>>
>>>         _______________________________________________
>>>         Opengnsys-users mailing list
>>>         Opengnsys-users en listas.unizar.es  <mailto:Opengnsys-users en listas.unizar.es>
>>>         https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
>>>         ----------
>>>         INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>>>
>>>         Ud. recibe este correo por pertenecer a una lista de correo gestionada por la Universidad de Zaragoza.
>>>         Puede encontrar toda la información sobre como tratamos sus datos en el siguiente enlace:https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
>>>         Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de baja desde la propia aplicación en el momento en que lo desee.
>>>         http://listas.unizar.es
>>>         ----------
>>
>>         _______________________________________________
>>         Opengnsys-users mailing list
>>         Opengnsys-users en listas.unizar.es
>>         <mailto:Opengnsys-users en listas.unizar.es>
>>         https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
>>         ----------
>>         INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>>
>>         Ud. recibe este correo por pertenecer a una lista de correo
>>         gestionada por la Universidad de Zaragoza.
>>         Puede encontrar toda la información sobre como tratamos sus
>>         datos en el siguiente enlace:
>>         https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
>>         Recuerde que si está suscrito a una lista voluntaria Ud.
>>         puede darse de baja desde la propia aplicación en el momento
>>         en que lo desee.
>>         http://listas.unizar.es
>>         ----------
>>
>>
>>     _______________________________________________
>>     Opengnsys-users mailing list
>>     Opengnsys-users en listas.unizar.es  <mailto:Opengnsys-users en listas.unizar.es>
>>     https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
>>     ----------
>>     INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>>
>>     Ud. recibe este correo por pertenecer a una lista de correo gestionada por la Universidad de Zaragoza.
>>     Puede encontrar toda la información sobre como tratamos sus datos en el siguiente enlace:https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
>>     Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de baja desde la propia aplicación en el momento en que lo desee.
>>     http://listas.unizar.es
>>     ----------
>
>
> _______________________________________________
> Opengnsys-users mailing list
> Opengnsys-users en listas.unizar.es
> https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
> ----------
> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>
> Ud. recibe este correo por pertenecer a una lista de correo gestionada por la Universidad de Zaragoza.
> Puede encontrar toda la información sobre como tratamos sus datos en el siguiente enlace: https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
> Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de baja desde la propia aplicación en el momento en que lo desee.
> http://listas.unizar.es
> ----------

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.unizar.es/pipermail/opengnsys-users/attachments/20210712/4f142657/attachment-0001.html>


Más información sobre la lista de distribución Opengnsys-users