BTFS: sistema de arquivos BitTorrent

 (github.com/johang)
3 pontos por GN⁺ 2024-04-17 | 1 comentários | Compartilhar no WhatsApp
  • BTFS é um sistema de arquivos BitTorrent que monta arquivos .torrent ou magnet links para uso como diretórios somente leitura em uma árvore de arquivos
  • O conteúdo dos arquivos é baixado sob demanda quando a aplicação o lê, e ferramentas comuns como ls, cat e cp funcionam como esperado
  • Aplicações como vlc e mplayer também podem funcionar sem modificações, permitindo tratar conteúdo de torrent como arquivos comuns
  • Fornece instruções de instalação de pacotes para Debian/Ubuntu, Arch Linux, Gentoo, Fedora, Fedora OSTree, OpenSUSE e macOS
  • As dependências no Linux são fuse3, libtorrent e libcurl, e a compilação a partir do código-fonte usa o fluxo autoreconf, configure, make

O que o BTFS faz

  • O BTFS monta arquivos .torrent ou magnet links para que possam ser usados como diretórios somente leitura dentro de uma árvore de arquivos
  • O conteúdo dos arquivos é baixado sob demanda quando a aplicação realmente o lê
  • Ferramentas comuns de sistema de arquivos funcionam normalmente
    • ls
    • cat
    • cp
  • As aplicações também podem ser usadas sem modificações
    • vlc
    • mplayer

Fluxo básico de uso

  • Crie um diretório de montagem, conecte o arquivo torrent e depois execute os arquivos dentro do diretório como arquivos comuns
$ mkdir mnt
$ btfs video.torrent mnt
$ cd mnt
$ vlc video.mp4
  • A desmontagem e o encerramento são feitos com fusermount
$ fusermount -u mnt

Instalação de pacotes

  • No Debian/Ubuntu, instale com apt-get
# apt-get install btfs
  • No Arch Linux, instale com pacman
# pacman -S btfs
  • No Gentoo, instale com emerge
# emerge -av btfs
  • No Fedora, instale o pacote fuse-btfs com dnf
# dnf install fuse-btfs
  • No Fedora OSTree, instale fuse-btfs com rpm-ostree
$ rpm-ostree install fuse-btfs
  • No OpenSUSE, instale com zypper
# zypper install btfs
  • No macOS, use brew
$ brew install btfs

Dependências no Linux

  • As dependências necessárias no Linux são as seguintes
    • fuse3: no Ubuntu 22.04, fuse3
    • libtorrent: no Ubuntu 22.04, libtorrent-rasterbar8
    • libcurl: no Ubuntu 22.04, libcurl4

Compilação a partir do código-fonte

  • Em versões recentes do Debian/Ubuntu, instale as dependências de compilação, depois faça o clone do repositório e execute autoreconf, configure e 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
  • Se também quiser instalar, execute make install adicionalmente
$ make install
  • A compilação no macOS usa o mesmo fluxo de build depois de instalar as dependências com brew
$ 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
  • No macOS também, se precisar instalar, execute make install
$ make install

Leituras relacionadas

1 comentários

 
GN⁺ 2024-04-17
Comentários no Hacker News

  • Seria bom ter um programa de servidor que fizesse par com isso. Algo que também atuasse como gerador de arquivos torrent, tracker e servidor simples de arquivos
    Em organizações grandes, daria para manter uma quantidade enorme de dados públicos no servidor, criar torrents sempre que os dados mudarem, servir os arquivos .torrent por HTTP e também fazer o papel de tracker
    Bastaria envolver o cliente FUSE com uma lógica simples para detectar novos torrents no servidor e recarregar/remontar Há muito tempo, fiz uma distribuição Linux para uso em bancos. Era baseada em Ubuntu NetBoot com só os pacotes mínimos para desktops de agências, e como não havia servidor nas agências, a distribuição fazia auto-seeding
    Com wake-on-lan e PXE configurados no switch, uma única máquina conseguia clonar centenas de outras no prédio em pouco tempo, e as novas cópias também podiam virar seeds
    Internamente, usávamos nginx para servir um repositório Ubuntu customizado e rodávamos tftp/inetd e wackamole. Quando uma máquina era instalada, ela recebia o torrent do “servidor” e o adicionava ao transmission; ao terminar, essa máquina também virava seed e subia wackamole, inetd, nginx, tracker etc. No começo, ela fazia seed estável para 10 máquinas e, quando todas subiam, acordávamos mais máquinas
    Distribuímos a imagem para 8000 máquinas em centenas de agências bancárias em poucas semanas, e a maior parte da demora veio de gestão de mudanças e do plano de rollout em fases. Na prática, a parte mais difícil foi fazer o primeiro seed chegar a cada agência pelo build Linux existente e então usar uma delas como máquina seed. Isso aconteceu em mais de 350 agências com links fracos, algumas com ISDN de 256 kbps

    • Um recurso que pode interessar; pelo que sei, só o AWS S3 implementou isso: https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObjec...
      Nunca usei isso na prática, então não sei se a AWS coloca o próprio tracker no .torrent resultante
    • Se um novo torrent for criado sempre que o conjunto de dados for atualizado, o cliente não vai acabar baixando de novo até os dados que não mudaram?

  • Esta ferramenta deveria ser atualizada para usar os novos recursos do BitTorrent v2
    https://blog.libtorrent.org/2020/09/bittorrent-v2/
    Em especial, a árvore de hash de Merkle, que permite árvores de hash por arquivo e estrutura de diretórios

    • Desde que descobri o BitTorrent v2, venho esperando que surjam índices por arquivo online. Seria ótimo poder marcar quantas cópias existem hoje no swarm do BitTorrent para a maior parte dos arquivos grandes de mídia no meu drive
      Assim eu poderia apagar arquivos grandes com mais tranquilidade, sabendo que depois conseguiria baixar a mesma cópia de novo com facilidade. Tentei algo parecido com IPFS no passado, mas não funcionou bem e também não encontrava arquivos duplicados

  • Seria ótimo ter um BTFS que consertasse arquivos de mídia “corrompidos”. Por exemplo, se um disco estiver arranhado e faltarem partes, ou se a mídia tiver ficado ruim por causa das opções de codec que escolhi, ele baixaria só as partes danificadas e faria uma recuperação transparente

    • Não é exatamente a mesma coisa, mas isso me lembrou o AccurateRip, que eu usava muito na época em que ripava centenas de CDs por ano
      http://www.accuraterip.com/
    • Por que não usar um sistema de arquivos que preserve isso? Existe ZFS, e armazenamento é barato
    • Outro caso de uso seria compartilhar a mídia depois de importá-la para minha biblioteca. Se eu pudesse escanear voluntariamente os hashes de toda a mídia que tenho, e um cliente de torrent inteligente pudesse oferecer só esses arquivos, isso ajudaria bastante a fazer seed de arquivos de mídia raros
      Eu sempre apago os arquivos desnecessários, então precisaria de algo no estilo torrent parcial
    • Se o arquivo estiver corrompido, como você vai calcular o hash para fazer a consulta?
    • Não daria para distribuir arquivos de paridade junto com o arquivo real, como se faz no Usenet? O próprio Usenet quase funciona assim
      Não sei se alguma implementação de sistema de arquivos sobre NNTP funciona direito, mas também existe o nzbfs: https://github.com/danielfullmer/nzbfs

  • Estou postando isso porque me surpreende que não seja mais usado. Não daria para criar máquinas virtuais ou sistemas operacionais como um overlay sobre BTFS? Parece uma direção interessante

    • Ainda na semana passada, criei imagens de boot PXE com Nix no meu notebook, subi tudo para IPFS e depois fiz boot pela rede do meu servidor em outro país via mirrors públicos de IPFS
      No boot, o initrd é montado como um overlayfs somente leitura. Deixei a configuração pública aqui: https://github.com/jhvst/nix-config
      Depois pretendo documentar o processo com a configuração do roteador PXE em https://github.com/majbacka-labs/nixos.fi. Também posso manter um pequeno servidor público de build para a configuração Flake para quem quiser testar esse processo
    • Não é exatamente um provedor de overlay, mas uber/kraken é um “registro Docker P2P capaz de distribuir dados em escala de terabytes em segundos”. Ele entrega imagens Docker a grandes clusters usando o protocolo BitTorrent
      https://github.com/uber/kraken
    • CVMFS é uma opção madura nessa área e é muito usado pela comunidade de física para distribuir software e imagens de contêiner. Ele permite compartilhar recursos computacionais de forma simples e eficiente
      https://cernvm.cern.ch/fs/
    • Não entendi muito bem a ideia. Um sistema de arquivos somente leitura que baixa arquivos sob demanda é legal, mas, na maioria das situações, isso não parece prático
    • De vez em quando alguém reinventa o Plan 9 da Bell Labs

  • É um cliente perfeito para acessar conteúdo do Internet Archive. Cada item do IA recebe automaticamente um torrent com o web seed do IA. Dá para testar com Big Buck Bunny
    btfs https://archive.org/download/BigBuckBunny_124/BigBuckBunny_1... mountpoint

    • Não conheço a estrutura interna do IA nem do BitTorrent, mas se houver itens demais em um item do arquivo, nem tudo entra no arquivo torrent
      Vejo isso com frequência em pacotes de ROMs ou arquivos de revistas. Quando há mais de 1000 itens, o torrent normalmente contém só os ~200 primeiros
    • Uma forma melhor é esta:
      btplay https://archive.org/download/BigBuckBunny_124/…

  • Posts relacionados:
    BTFS – mount any .torrent file or magnet link as directory - https://news.ycombinator.com/item?id=23576063 - junho de 2020 (121 comentários)
    BitTorrent file system - https://news.ycombinator.com/item?id=10826154 - jan. de 2016 (33 comentários)

  • Indo além, seria bom armazenar os dados em um arquivo sqlite com um índice de busca full-text. Aí seria possível fazer busca full-text em torrents quando necessário: https://github.com/bittorrent/sqltorrent

  • Discussão de 4 anos atrás:
    https://news.ycombinator.com/item?id=23576063

  • No tópico anterior de 2020 com 121 comentários, o comentário no topo do saurik resume bem o que sinto sobre isso: https://news.ycombinator.com/item?id=23580334
    BTFS seria a versão do IPFS de “um CID por vez”
    IPFS é legal, mas para virar algo realmente útil no dia a dia, acho que ainda precisa de grandes avanços em pelo menos três áreas. Primeiro, não deveria ser necessário rodar um proxy de nó local. Ouvi dizer que o Brave tem suporte a WebTorrent embutido, mas como não uso Brave, não sei se é só o nome WebTorrent ou se de fato funciona assim
    Segundo, a latência de resolução de swarm/peer é dolorosa no mesmo nível das “brincadeiras cripto da web3”, e essa latência faz a navegação parecer os tempos antigos do modem 14.4k
    Terceiro, IPFS é excelente para conteúdo que muda raramente, mas é muito popular, como Wikipedia, lançamentos de jogos e conteúdo do MDN. Mas, pensando em navegar por um repositório git, trocar “tip” ou “main” por uma versão atualizada é bem incômodo. Até onde sei, a única forma de resolver o CID mais recente é via IPNS, e DNS é um mecanismo que facilmente vira mais um dos vários elementos envolvidos sempre que há uma falha
    Sei que escrevi demais sobre um sistema de arquivos diferente daquele enviado, mas embora eu provavelmente não vá instalar o BTFS, quem se interessa por essa ideia talvez devesse ler mais sobre IPFS. Só vale a pena ter em mente as limitações atuais

  • https://github.com/anacrolix/torrent tinha um driver FUSE desde 2013. Agora está nos estágios iniciais de removê-lo
    WebDAV, FUSE de terceiros e wrappers HTTP estão todos fazendo algo parecido. A ideia é expor links magnet, info hashes e arquivos torrent como se fossem um sistema de arquivos imutável. O suporte a BitTorrent v2 atualmente está no master