Ipfs: Ipfs 0.4.10 falla al agregar archivos de más de 50 MB

Creado en 13 jul. 2017  ·  9Comentarios  ·  Fuente: ipfs/ipfs

Sistema operativo: Arch Linux y MacOS

~ % ipfs version
ipfs version 0.4.10
~ % ipfs init
initializing IPFS node at /Users/user/.ipfs
generating 2048-bit RSA keypair...done
peer identity: Qme3fGyQWP4mf3J9Ln3EjofWyYhiGgVCZZ41jgVA9o78u7
to get started, enter:

    ipfs cat /ipfs/QmVLDAhCY3X9P2uRudKAryuQFPM5zqA3Yij1dY8FpGbL7T/readme

~ % ipfs daemon
Initializing daemon...
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/192.168.0.102/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

Intentemos agregar un video:

ipfs add raw_video.mkv
added Qmf6vier2j9rtG7hjA8Bf8ohzT5VYNmGfRntSc4zXsQyPL raw_video.mkv

Unos 15-20 segundos después, ipfs se bloqueará:
https://gist.github.com/Netherdrake/4da51b24da82fe25ae476cffeb09cc31

Este problema es intermitente; a veces, la adición se realiza correctamente y puedo acceder a los archivos en localhost:8080/ipfs/HASH/raw_video.mkv sin problemas, pero la mayoría de las veces, el demonio se bloquea.

Comentario más útil

bien, entonces este es un caso de agregar un archivo que hace que el subsistema del proveedor de DHT se conecte a demasiados pares. Si elimina la marca --routing=none y usa ipfs add --local cosas también deberían funcionar bien.

Estoy trabajando en una solución para esto, con suerte tendremos algo en la próxima versión.

Todos 9 comentarios

Puede redirigir por ipfs daemon 2>stderr.log

Tampoco puedo reproducirlo, he intentado con archivos de 10x60MiB.

Resulta que ipfs fallará al agregar cualquier archivo grande.

Por ejemplo, ISO oficial de Ubuntu.

En MacOS se bloquea:

ipfs add ubuntu-16.04.2-desktop-amd64.iso
 488.00 MB / 1.45 GB [=============================>------------------------------------------------------------]  32.92% 20s17:54:27.509 ERROR commands/h: unexpected EOF client.go:247
Error: unexpected EOF

En Linux, falla, pero el proceso del demonio parece seguir ejecutándose:

~/Downloads % ipfs add ubuntu-16.04.2-desktop-amd64.iso 
 32.00 MB / 1.45 GB [=>----------------------------------------------------------------------------]   2.16% 30s17:53:01.534 ERROR commands/h: open /home/user/.ipfs/blocks/SF/put-579906520: too many open files client.go:247
Error: open /home/user/.ipfs/blocks/SF/put-579906520: too many open files
% ipfs daemon
Initializing daemon...
Adjusting current ulimit to 2048...
Successfully raised file descriptor limit to 2048.
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/172.17.0.1/tcp/4001
Swarm listening on /ip4/172.18.0.1/tcp/4001
Swarm listening on /ip4/172.19.0.1/tcp/4001
Swarm listening on /ip4/172.20.0.1/tcp/4001
Swarm listening on /ip4/172.21.0.1/tcp/4001
Swarm listening on /ip4/172.22.0.1/tcp/4001
Swarm listening on /ip4/172.23.0.1/tcp/4001
Swarm listening on /ip4/172.24.0.1/tcp/4001
Swarm listening on /ip4/192.168.1.107/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready
17:53:01.534 ERROR commands/h: err: open /home/user/.ipfs/blocks/SF/put-579906520: too many open files handler.go:285

He intentado cambiar a versiones anteriores, y la única versión que no falla es 0.4.6 :

~/Downloads % ipfs add ubuntu-16.04.2-desktop-amd64.iso 
added QmTc9mzzoEChP2Wyc4uGWGkkifC99y8o4KmxwVyg18MP76 ubuntu-16.04.2-desktop-amd64.iso
~/Downloads % ipfs version
ipfs version 0.4.6
~/Downloads % pacman -Q go-ipfs
go-ipfs 0.4.6-1

No puedo reproducir esto en macOS 10.12.5 y Ubuntu 16.04 usando ipfs 0.4.10.

$ truncate -s 500M testfile
added QmV7q5aTmvZtGWja4wpodiUTEpBVWYFkQGRQ8PmJMDPG62 testfile
$

¿Fue su compilación de ipfs desde la fuente, su administrador de paquetes o el binario de la web? Tal vez intente con un directorio ~/.ipfs limpio para ver si el problema persiste.

Todos son de administradores de paquetes. Cada salida en los mensajes anteriores comenzó con rm -rf ~/.ipfs && ipfs init .

@Netherdrake si ejecuta su daemon con la opción --routing=none , ¿sigue fallando de la misma manera?

Con --routing=none funciona bien.

bien, entonces este es un caso de agregar un archivo que hace que el subsistema del proveedor de DHT se conecte a demasiados pares. Si elimina la marca --routing=none y usa ipfs add --local cosas también deberían funcionar bien.

Estoy trabajando en una solución para esto, con suerte tendremos algo en la próxima versión.

Oh, también me doy cuenta de que este problema está en el repositorio incorrecto. En el futuro, use ipfs/go-ipfs para informar problemas como este.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

timthelion picture timthelion  ·  28Comentarios

nbingham1 picture nbingham1  ·  19Comentarios

jbenet picture jbenet  ·  34Comentarios

PayasR picture PayasR  ·  10Comentarios

daviddias picture daviddias  ·  29Comentarios