BTFS: BitTorrent Filesystem

Original Article ↗ Hacker News Discussion ↗

What BTFS Is and Core Use Case

  • BTFS mounts a .torrent or magnet link as a read-only directory, downloading pieces on demand and seeding while present.
  • Some see it mainly as “a nicer BitTorrent client” or a convenient way to access content like Internet Archive torrents or large media collections without pre-downloading everything.
  • Others find it attractive for scenarios where many machines read the same large data set (e.g., software images, updates) and can share bandwidth via P2P.

Ambitious Ideas and Experimental Uses

  • Proposals include layering whole OSes/VMs over BTFS, immutable systems, or PXE/netboot flows that mount read-only overlays from P2P sources.
  • Similar concepts exist: a torrent-backed block device for booting VMs, P2P Docker/OCI image distribution, and using content-addressed storage for NixOS and IPFS-based netbooting.
  • Some speculate about broader architectures: memoizing computations by hash, fully distributed OSes/VMs/LLMs, and P2P app stores or Snap-like package systems.

Limitations and Skepticism

  • Many workloads (media playback, software, VMs, LLMs) effectively require a full local copy, reducing the benefit of partial/lazy fetching.
  • Performance depends heavily on seeder count; slow or sparse swarms can cause application timeouts and poor UX.
  • Automation is hard: moving files breaks seeding, and some programs expect synchronous, fast file access.
  • Security model is largely unspecified in the discussion; several participants question what threats are addressed, if any.

Comparisons and Related Systems

  • BTFS is contrasted with IPFS: BTFS is torrent-oriented and “one content ID at a time,” while IPFS offers global content addressing and better random access but suffers from latency, reliance on local nodes, and awkward handling of “latest version” pointers.
  • Other related tools mentioned: CVMFS for scientific software, P2P registries like Kraken/Spegel, distributed FSs (Ceph, GlusterFS), sync tools (Syncthing, Resilio Sync), Tahoe-LAFS, AeroFS, and various content-addressed or torrent-FUSE projects.

BitTorrent v2, Indexing, and Data Integrity

  • Participants note BT v2’s per-file Merkle trees and directory support as highly relevant, enabling per-file hashes and better indexing.
  • There is interest in tagging local files with their swarm availability, repairing damaged media via torrents, and protecting against bit rot (with mentions of parity, ZFS, and external checksum databases), but practical, general solutions remain unclear.