3P by GN⁺ | ★ favorite | 댓글 1개
  • BTFS.torrent 파일이나 magnet link를 파일 트리의 읽기 전용 디렉터리처럼 마운트해 사용하는 비트토렌트 파일 시스템임
  • 파일 내용은 애플리케이션이 읽을 때 온디맨드로 다운로드되며, ls, cat, cp 같은 일반 도구가 예상대로 동작함
  • vlc, mplayer 같은 애플리케이션도 변경 없이 동작할 수 있어, 토렌트 콘텐츠를 일반 파일처럼 다룰 수 있음
  • Debian/Ubuntu, Arch Linux, Gentoo, Fedora, Fedora OSTree, OpenSUSE, macOS에서 패키지 설치 방법을 제공함
  • Linux 의존성은 fuse3, libtorrent, libcurl이며, 소스 빌드는 autoreconf, configure, make 흐름을 사용함

BTFS가 하는 일

  • BTFS.torrent 파일 또는 magnet link를 마운트해 파일 트리 안의 읽기 전용 디렉터리처럼 사용할 수 있게 함
  • 파일 내용은 애플리케이션이 실제로 읽을 때 온디맨드 다운로드
  • 일반 파일 시스템 도구가 그대로 동작함
    • ls
    • cat
    • cp
  • 애플리케이션도 변경 없이 사용할 수 있음
    • vlc
    • mplayer

기본 사용 흐름

  • 마운트 디렉터리를 만들고 토렌트 파일을 연결한 뒤, 디렉터리 안의 파일을 일반 파일처럼 실행함
$ mkdir mnt
$ btfs video.torrent mnt
$ cd mnt
$ vlc video.mp4
  • 마운트 해제와 종료는 fusermount로 수행함
$ fusermount -u mnt

패키지 설치

  • Debian/Ubuntu에서는 apt-get으로 설치함
# apt-get install btfs
  • Arch Linux에서는 pacman으로 설치함
# pacman -S btfs
  • Gentoo에서는 emerge로 설치함
# emerge -av btfs
  • Fedora에서는 dnffuse-btfs 패키지를 설치함
# dnf install fuse-btfs
  • Fedora OSTree에서는 rpm-ostreefuse-btfs를 설치함
$ rpm-ostree install fuse-btfs
  • OpenSUSE에서는 zypper로 설치함
# zypper install btfs
  • macOS에서는 brew를 사용함
$ brew install btfs

Linux 의존성

  • Linux에서 필요한 의존성은 다음과 같음
    • fuse3: Ubuntu 22.04에서는 fuse3
    • libtorrent: Ubuntu 22.04에서는 libtorrent-rasterbar8
    • libcurl: Ubuntu 22.04에서는 libcurl4

소스 빌드

  • 최근 Debian/Ubuntu에서는 빌드 의존성을 설치한 뒤 저장소를 클론하고 autoreconf, configure, 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
  • 설치까지 원하면 make install을 추가로 실행함
$ make install
  • macOS 빌드는 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
  • macOS에서도 설치가 필요하면 make install을 실행함
$ make install

댓글과 토론

Hacker News 의견들
  • 이와 짝을 이루는 서버 프로그램이 있으면 좋겠음. 토렌트 파일 생성기, 트래커, 단순 파일 서버 역할을 같이 하는 것 말임
    큰 조직에서는 서버에 엄청난 양의 공개 데이터를 두고, 데이터가 바뀔 때마다 토렌트를 만들고, .torrent 파일은 HTTP로 제공하면서 트래커 역할도 하게 할 수 있을 듯함. FUSE 클라이언트에는 서버의 새 토렌트를 감지해 다시 로드/마운트하는 간단한 로직을 감싸면 됨
    오래전에 은행용 Linux 배포판을 만든 적이 있음. Ubuntu NetBoot 기반에 지점 데스크톱용 최소 패키지만 넣었고, 지점에는 서버가 없어서 배포판이 자가 시딩을 했음. wake-on-lan과 PXE만 스위치에 설정되어 있으면 한 대로 건물 안 수백 대를 꽤 짧은 시간에 복제할 수 있었고, 새 복제본도 시드가 될 수 있었음
    내부적으로는 nginx로 커스텀 Ubuntu 저장소를 제공하고 tftp/inetd와 wackamole을 돌렸음. 머신이 설치되면 “서버”에서 토렌트를 받아 transmission에 추가했고, 완료 후에는 그 머신도 시드가 되어 wackamole, inetd, nginx, tracker 등을 띄웠음. 처음엔 10대를 안정적으로 시딩하고, 모두 올라오면 더 많은 머신을 깨우는 식이었음
    은행 지점 수백 곳에 걸쳐 몇 주 만에 8000대에 이미지를 배포했는데, 지연 대부분은 변경 관리와 단계적 배포 계획 때문이었음. 실제로 가장 어려웠던 건 기존 Linux 빌드를 통해 각 지점에 첫 시드를 내려받고 그중 하나를 시드 머신으로 쓰게 하는 일이었음. 350개 이상 지점에서 부족한 회선, 일부는 256kbps ISDN으로 진행했음

    • 관심 있을 만한 기능인데, 아는 한 AWS S3만 구현한 것 같음: https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObjec...
      실제로 써본 적은 없어서 AWS가 결과 .torrent에 자체 트래커를 넣는지는 모름
    • 데이터셋이 업데이트될 때마다 새 토렌트를 만들면, 클라이언트가 바뀌지 않은 데이터까지 다시 전송받게 되지 않나?
  • 이 도구는 BitTorrent v2의 새 기능을 쓰도록 업그레이드되어야 함
    https://blog.libtorrent.org/2020/09/bittorrent-v2/
    특히 파일별 해시 트리와 디렉터리 구조를 가능하게 하는 머클 해시 트리가 중요함

    • BitTorrent v2를 알게 된 뒤로 온라인에 파일별 색인이 생기길 기대해 왔음. 내 드라이브의 대용량 미디어 파일 대부분에 대해 지금 BitTorrent 스웜에 복사본이 몇 개 있는지 태그할 수 있으면 좋겠음
      그러면 나중에 동일한 복사본을 쉽게 다시 받을 수 있다는 걸 알고 큰 파일을 더 쉽게 삭제할 수 있음. 예전에 IPFS로 비슷한 걸 해보려 했지만 잘 안 됐고 중복 파일도 못 찾았음
  • “손상된” 미디어 파일을 고쳐주는 BTFS가 있으면 좋겠음. 예를 들어 디스크에 흠집이 나서 일부가 빠졌거나, 내가 고른 코덱 옵션이 별로였던 미디어라면 손상된 부분만 내려받아 매끄럽게 복구해주는 식임

    • 정확히 같은 건 아니지만, 예전에 매년 CD 수백 장을 리핑하던 시절에 많이 쓰던 AccurateRip이 떠오름
      http://www.accuraterip.com/
    • 왜 그런 걸 유지해주는 파일 시스템을 쓰지 않나? ZFS도 있고, 저장소도 저렴함
    • 또 다른 용도는 미디어를 내 라이브러리에 가져온 뒤 공유하는 것임. 내가 가진 모든 미디어의 해시를 자발적으로 스캔하고, 똑똑한 토렌트 클라이언트가 그 파일들만 제공할 수 있다면 희귀 미디어 파일 시딩에 큰 도움이 됨
      항상 불필요한 파일은 지우기 때문에 부분 토렌트 형태가 필요함
    • 파일이 망가졌는데 조회용 해시는 어떻게 계산할 건가?
    • Usenet에서 하듯 실제 파일과 함께 패리티 파일을 배포하면 되지 않을까? Usenet 자체가 거의 이런 방식이기도 함
      NNTP 파일 시스템 구현이 제대로 동작하는지는 모르겠지만, nzbfs도 있음: https://github.com/danielfullmer/nzbfs
  • 이게 더 많이 쓰이지 않는 게 신기해서 올림. 가상 머신이나 운영체제를 BTFS 위 오버레이로 만들 수 있지 않을까? 흥미로운 방향으로 보임

    • 바로 지난주에 노트북에서 Nix로 PXE 부트 이미지를 만들고, 그것들을 IPFS에 올린 뒤, 다른 나라에 있는 내 서버를 공개 IPFS 미러를 통해 네트워크 부팅했음
      부팅 시 initrd는 읽기 전용 overlayfs로 마운트됨. 설정은 공개해 둠: https://github.com/jhvst/nix-config
      나중에 PXE 라우터 설정을 포함한 IPFS 과정 문서를 https://github.com/majbacka-labs/nixos.fi에 쓸 계획임. 이 과정을 시험해보고 싶은 사람들을 위해 Flake 설정용 작은 공개 빌드 서버도 운영할 수 있음
    • 오버레이 제공자 자체는 아니지만, uber/kraken은 “몇 초 만에 TB 단위 데이터를 배포할 수 있는 P2P Docker 레지스트리”임. BitTorrent 프로토콜로 대규모 클러스터에 Docker 이미지를 전달함
      https://github.com/uber/kraken
    • CVMFS는 이 영역에서 성숙한 선택지이고, 물리학 커뮤니티에서 소프트웨어와 컨테이너 이미지를 배포하는 데 많이 쓰임. 컴퓨팅 자원을 단순하고 효율적으로 공유할 수 있게 해줌
      https://cernvm.cern.ch/fs/
    • 요점을 잘 모르겠음. 즉석에서 파일을 내려받는 읽기 전용 파일 시스템은 멋지지만, 대부분의 상황에서는 실용적으로 들리지 않음
    • 가끔 누군가가 Bell Labs의 Plan 9을 다시 발명함
  • Internet Archive 콘텐츠에 접근하기에 완벽한 클라이언트임. IA의 각 항목에는 IA의 웹 시드가 들어간 토렌트가 자동으로 붙음. Big Buck Bunny로 시험해볼 수 있음
    btfs https://archive.org/download/BigBuckBunny_124/BigBuckBunny_1... mountpoint

    • IA 내부와 BitTorrent 구조는 모르지만, 아카이브 항목이 너무 많으면 토렌트 파일에 전부 들어가지 않음
      ROM 묶음이나 잡지 아카이브에서 자주 봄. 항목이 1000개를 넘으면 토렌트에는 보통 처음 약 200개만 있음
    • 더 나은 방법은 이거임:
      btplay https://archive.org/download/BigBuckBunny_124/…
  • 관련 글:
    BTFS – mount any .torrent file or magnet link as directory - https://news.ycombinator.com/item?id=23576063 - June 2020 (121 comments)
    BitTorrent file system - https://news.ycombinator.com/item?id=10826154 - Jan 2016 (33 comments)

  • 더 나아가 데이터를 전체 텍스트 검색 색인이 들어간 sqlite 파일로 저장하면 좋음. 그러면 토렌트를 필요할 때 전체 텍스트 검색할 수 있음: https://github.com/bittorrent/sqltorrent

  • 4년 전 논의:
    https://news.ycombinator.com/item?id=23576063

  • 2020년의 121개 댓글짜리 이전 스레드에서 saurik의 최상위 댓글이 이 상황에 대한 내 느낌을 잘 요약함: https://news.ycombinator.com/item?id=23580334
    BTFS는 IPFS의 “한 번에 CID 하나” 버전이라는 것임
    IPFS는 멋지지만 일상적으로 쓸 만해지려면 최소 세 영역에서 큰 진전이 필요하다고 봄. 첫째, 로컬 노드 프록시를 돌리지 않아야 함. Brave에 WebTorrent 지원이 내장되어 있다는 얘기는 들었지만, Brave를 쓰지 않아서 이름만 WebTorrent인지 어떤지는 모름
    둘째, 스웜/피어 해석 지연 시간이 “web3 암호화폐 장난”과 같은 식으로 고통스럽고, 그 지연 때문에 탐색이 예전 14.4k 모뎀 시절처럼 느껴짐
    셋째, IPFS는 Wikipedia, 게임 릴리스, MDN 콘텐츠처럼 드물게 바뀌지만 매우 인기 있는 콘텐츠에는 훌륭함. 하지만 git 저장소를 탐색한다고 생각했을 때 “tip”이나 “main”을 업데이트된 버전으로 바꾸는 건 상당히 번거로움. 아는 한 최신 CID를 해석하는 방법은 IPNS뿐이고, DNS는 장애 때마다 얽히는 여러 요소 중 하나가 되기 쉬운 메커니즘임
    제출된 파일 시스템이 아닌 다른 파일 시스템에 대해 지나치게 길게 쓴 건 알지만, BTFS는 설치하지 않을 것 같은 반면 이 아이디어에 관심 있는 사람은 IPFS를 더 읽어볼 만함. 다만 현재의 한계는 염두에 두는 게 좋음

  • https://github.com/anacrolix/torrent에는 2013년부터 FUSE 드라이버가 있었음. 지금은 그것을 제거하는 초기 단계에 있음
    WebDAV, 서드파티 FUSE, HTTP 래퍼가 모두 비슷한 일을 하고 있음. 마그넷 링크, 정보 해시, 토렌트 파일을 불변 파일 시스템처럼 제공하는 방식임. BitTorrent v2 지원은 현재 master에 들어가 있음