3 puntos por GN⁺ 2024-04-17 | 1 comentarios | Compartir por WhatsApp
  • BTFS es un sistema de archivos BitTorrent que permite montar archivos .torrent o magnet links como directorios de solo lectura dentro de un árbol de archivos
  • El contenido de los archivos se descarga bajo demanda cuando una aplicación lo lee, y herramientas comunes como ls, cat y cp funcionan como se espera
  • Aplicaciones como vlc y mplayer también pueden funcionar sin cambios, lo que permite tratar el contenido de torrents como archivos normales
  • Ofrece métodos de instalación de paquetes para Debian/Ubuntu, Arch Linux, Gentoo, Fedora, Fedora OSTree, OpenSUSE y macOS
  • En Linux, las dependencias son fuse3, libtorrent y libcurl; la compilación desde el código fuente usa el flujo autoreconf, configure, make

Qué hace BTFS

  • BTFS permite montar un archivo .torrent o magnet link para usarlo como un directorio de solo lectura dentro del árbol de archivos
  • El contenido de los archivos se descarga bajo demanda cuando una aplicación lo lee realmente
  • Las herramientas normales del sistema de archivos funcionan tal cual
    • ls
    • cat
    • cp
  • Las aplicaciones también pueden usarse sin cambios
    • vlc
    • mplayer

Flujo básico de uso

  • Crea un directorio de montaje, conecta el archivo torrent y luego ejecuta los archivos dentro del directorio como archivos normales
$ mkdir mnt
$ btfs video.torrent mnt
$ cd mnt
$ vlc video.mp4
  • El desmontaje y la finalización se realizan con fusermount
$ fusermount -u mnt

Instalación de paquetes

  • En Debian/Ubuntu se instala con apt-get
# apt-get install btfs
  • En Arch Linux se instala con pacman
# pacman -S btfs
  • En Gentoo se instala con emerge
# emerge -av btfs
  • En Fedora se instala el paquete fuse-btfs con dnf
# dnf install fuse-btfs
  • En Fedora OSTree se instala fuse-btfs con rpm-ostree
$ rpm-ostree install fuse-btfs
  • En OpenSUSE se instala con zypper
# zypper install btfs
  • En macOS se usa brew
$ brew install btfs

Dependencias en Linux

  • Las dependencias necesarias en Linux son las siguientes
    • fuse3: en Ubuntu 22.04 es fuse3
    • libtorrent: en Ubuntu 22.04 es libtorrent-rasterbar8
    • libcurl: en Ubuntu 22.04 es libcurl4

Compilación desde el código fuente

  • En Debian/Ubuntu recientes, instala las dependencias de compilación, clona el repositorio y ejecuta autoreconf, configure y make
$ sudo apt-get install autoconf automake libfuse3-dev libtorrent-rasterbar-dev libcurl4-openssl-dev g++
$ git clone https://github.com/johang/btfs.git btfs
$ cd btfs
$ autoreconf -i
$ ./configure
$ make
  • Si también quieres instalarlo, ejecuta además make install
$ make install
  • Para compilar en macOS, instala las dependencias con brew y usa el mismo flujo de compilación
$ brew install --cask macfuse libtorrent-rasterbar autoconf automake pkg-config
$ git clone https://github.com/johang/btfs.git btfs
$ cd btfs
$ autoreconf -i
$ ./configure
$ make
  • Si también necesitas instalarlo en macOS, ejecuta make install
$ make install

1 comentarios

 
GN⁺ 2024-04-17
Opiniones en Hacker News
  • Sería bueno que hubiera un programa servidor que lo acompañe. Es decir, que funcione a la vez como generador de archivos torrent, tracker y servidor de archivos simple.
    En organizaciones grandes, podrían poner enormes cantidades de datos públicos en un servidor, crear torrents cada vez que cambien los datos, servir los archivos .torrent por HTTP y también actuar como tracker. En el cliente FUSE bastaría con envolver una lógica simple para detectar nuevos torrents del servidor y volver a cargarlos/montarlos.
    Hace mucho hice una distribución de Linux para un banco. Estaba basada en Ubuntu NetBoot, con solo los paquetes mínimos para desktops de sucursal, y como en las sucursales no había servidores, la distribución hacía seeding de sí misma. Con que wake-on-lan y PXE estuvieran configurados en el switch, una sola máquina podía clonar cientos de equipos dentro del edificio en bastante poco tiempo, y las nuevas copias también podían convertirse en seeds.
    Internamente servíamos un repositorio Ubuntu personalizado con nginx y corríamos tftp/inetd y wackamole. Cuando se instalaba una máquina, bajaba el torrent desde el “servidor” y lo agregaba a transmission; al terminar, esa máquina también se convertía en seed y levantaba wackamole, inetd, nginx, tracker, etc. Al principio se hacía seeding estable a 10 máquinas y, cuando todas estaban arriba, se despertaban más equipos.
    Distribuimos imágenes a 8000 equipos en cientos de sucursales bancarias en cuestión de semanas, y la mayor parte de la demora se debió a la gestión de cambios y al plan de despliegue gradual. En la práctica, lo más difícil fue bajar el primer seed a cada sucursal mediante la build de Linux existente y usar una de esas máquinas como seed. Se hizo en más de 350 sucursales con enlaces deficientes, algunas con ISDN de 256kbps.

    • Una función que podría interesarles y que, hasta donde sé, solo implementó AWS S3: https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObjec...
      Nunca la usé realmente, así que no sé si AWS incluye su propio tracker en el .torrent resultante.
    • Si se crea un torrent nuevo cada vez que se actualiza el dataset, ¿no terminarían los clientes volviendo a recibir incluso los datos que no cambiaron?
  • Esta herramienta debería actualizarse para usar las nuevas funciones de BitTorrent v2.
    https://blog.libtorrent.org/2020/09/bittorrent-v2/
    En especial, son importantes los árboles de hash de Merkle, que permiten árboles de hash por archivo y estructuras de directorios.

    • Desde que me enteré de BitTorrent v2, espero que aparezca un índice por archivo en línea. Me gustaría poder etiquetar, para la mayoría de los archivos multimedia grandes de mi disco, cuántas copias existen ahora mismo en swarms de BitTorrent.
      Así podría borrar archivos grandes con más facilidad sabiendo que más adelante puedo volver a bajar fácilmente una copia idéntica. Hace tiempo intenté hacer algo parecido con IPFS, pero no funcionó bien y tampoco encontró archivos duplicados.
  • Me gustaría que existiera un BTFS que arreglara archivos multimedia “dañados”. Por ejemplo, si a un disco le faltan partes por rayones, o si el medio quedó mal por las opciones de códec que elegí, que descargue solo las partes dañadas y las repare de forma fluida.

    • No es exactamente lo mismo, pero me recuerda a AccurateRip, que se usaba mucho en la época en que ripeábamos cientos de CDs por año.
      http://www.accuraterip.com/
    • ¿Por qué no usar un sistema de archivos que mantenga eso? Existe ZFS, y el almacenamiento es barato.
    • Otro uso sería compartir medios después de incorporarlos a mi biblioteca. Si pudiera escanear voluntariamente los hashes de todos los medios que tengo, y un cliente torrent inteligente pudiera ofrecer solo esos archivos, ayudaría mucho a hacer seeding de archivos multimedia raros.
      Como siempre borro los archivos innecesarios, necesitaría algún tipo de torrent parcial.
    • Si el archivo está dañado, ¿cómo vas a calcular el hash para buscarlo?
    • ¿No bastaría con distribuir archivos de paridad junto con los archivos reales, como se hace en Usenet? Usenet en sí funciona casi de esa manera.
      No sé si una implementación de sistema de archivos NNTP funciona bien, pero también existe nzbfs: https://github.com/danielfullmer/nzbfs
  • Lo publico porque me sorprende que esto no se use más. ¿No se podrían crear máquinas virtuales u OS como un overlay sobre BTFS? Parece una dirección interesante.

    • Justo la semana pasada creé imágenes de arranque PXE con Nix en mi laptop, las subí a IPFS y luego arranqué por red mi servidor en otro país a través de un mirror público de IPFS.
      Al arrancar, el initrd se monta como un overlayfs de solo lectura. Dejé pública la configuración: https://github.com/jhvst/nix-config
      Más adelante pienso documentar el proceso con IPFS, incluida la configuración del router PXE, en https://github.com/majbacka-labs/nixos.fi. También podría operar un pequeño servidor público de builds para la configuración Flake, para quienes quieran probar este proceso.
    • Aunque no es en sí un proveedor de overlays, uber/kraken es un “registro Docker P2P capaz de distribuir TB de datos en segundos”. Entrega imágenes Docker a clusters grandes mediante el protocolo BitTorrent.
      https://github.com/uber/kraken
    • CVMFS es una opción madura en este ámbito y se usa mucho en la comunidad de física para distribuir software e imágenes de contenedores. Permite compartir recursos de cómputo de forma simple y eficiente.
      https://cernvm.cern.ch/fs/
    • No entiendo bien el punto. Un sistema de archivos de solo lectura que descarga archivos sobre la marcha suena genial, pero en la mayoría de las situaciones no parece práctico.
    • De vez en cuando alguien reinventa Plan 9 de Bell Labs.
  • Es un cliente perfecto para acceder a contenido de Internet Archive. A cada ítem de IA se le adjunta automáticamente un torrent que incluye las semillas web de IA. Se puede probar con Big Buck Bunny
    btfs https://archive.org/download/BigBuckBunny_124/BigBuckBunny_1... mountpoint

    • No conozco los detalles internos de IA ni la estructura de BitTorrent, pero si un ítem del archivo tiene demasiadas cosas, no entran todas en el archivo torrent
      Lo veo seguido en paquetes de ROM o archivos de revistas. Si un ítem supera los 1000 archivos, el torrent normalmente solo incluye los primeros unos 200
    • Una mejor forma es esta:
      btplay https://archive.org/download/BigBuckBunny_124/…
  • Artículos relacionados:
    BTFS – mount any .torrent file or magnet link as directory - https://news.ycombinator.com/item?id=23576063 - junio de 2020 (121 comentarios)
    BitTorrent file system - https://news.ycombinator.com/item?id=10826154 - enero de 2016 (33 comentarios)

  • Sería bueno ir más allá y guardar los datos como un archivo sqlite con un índice de búsqueda de texto completo. Así se podrían hacer búsquedas de texto completo en torrents cuando haga falta: https://github.com/bittorrent/sqltorrent

  • Discusión de hace 4 años:
    https://news.ycombinator.com/item?id=23576063

  • El comentario principal de saurik en el hilo anterior de 2020, con 121 comentarios, resume bien cómo me siento sobre esta situación: https://news.ycombinator.com/item?id=23580334
    La idea es que BTFS es la versión de IPFS de “un CID a la vez”
    IPFS está buenísimo, pero creo que necesita avances importantes en al menos tres áreas para que se vuelva usable en el día a día. Primero, no debería hacer falta correr un proxy de nodo local. Escuché que Brave trae soporte integrado para WebTorrent, pero como no uso Brave, no sé si es solo WebTorrent de nombre o qué
    Segundo, la latencia de resolución de swarm/pares es dolorosa, al estilo de las “tonterías cripto de web3”, y por esa latencia navegar se siente como volver a la época de los módems de 14.4k
    Tercero, IPFS es excelente para contenido que cambia rara vez pero es muy popular, como Wikipedia, lanzamientos de juegos o contenido de MDN. Pero si uno piensa en navegar un repositorio git, cambiar “tip” o “main” a una versión actualizada es bastante engorroso. Hasta donde sé, la única forma de resolver el CID más reciente es IPNS, y DNS es un mecanismo que fácilmente se convierte en uno de los muchos factores que se enredan ante cada falla
    Sé que me extendí demasiado sobre un sistema de archivos distinto del enviado, pero aunque probablemente no instalaría BTFS, a quienes les interese esta idea les conviene leer más sobre IPFS. Eso sí, conviene tener presentes sus limitaciones actuales

  • https://github.com/anacrolix/torrent tenía un driver FUSE desde 2013. Ahora está en las primeras etapas de quitarlo
    WebDAV, FUSE de terceros y wrappers HTTP hacen cosas parecidas. Ofrecen enlaces magnet, hashes de información y archivos torrent como si fueran sistemas de archivos inmutables. El soporte para BitTorrent v2 ya está actualmente en master