How SpliceFS compares

SpliceFS aims to become a complete distributed filesystem. Today it is step one of that road: a read-only share where a reader pulls the same files from several servers at once. The other systems on this page are mature. This page says plainly what each one aims to be, and how far along it is.

Where SpliceFS is today

It is alpha software. The first 0.x versions are published; none has run in production.
It has never run in production. Its own tests are the only proof that it works.
Its protocol and its configuration may still change.
It only reads. Writing, file locks and keeping copies in step are plans, not features.
Its access control is basic: users with a password and a list of shares.
Nobody outside the project has reviewed its security, and no speed measurements are published.
It runs on Linux and macOS. There is no Windows version.

It does not replace any system on this page today. If you need something to depend on now, use one of them.

Side by side

The other systems are described as they are usually deployed. Each has options this table leaves out. The row titles and the SpliceFS column stay in place. Scroll the rest sideways, or tap a system to put it next to SpliceFS.

Yes, or a strength
Partly, or with limits
No, not yet, or a weakness
Does not apply
How far along its own road, out of five

Next to SpliceFS:

	This project	Network shares		Cluster filesystems		Peer to peer			Cloud storage tool
	SpliceFS
Aims to be	A complete distributed filesystem: read and write, cohorts of servers like RAID, transactional changes, distributed locks, full POSIX behavior, the same for local and remote clients, with data kept where you choose. Read-only is step one.	The standard network file share of Unix systems	The standard network file share of Windows and offices	A complete filesystem on a self-healing storage cluster, at any size	A scale-out filesystem on ordinary servers, with no metadata server	A fixed set of files shared by a swarm of peers, mounted as a folder	Fast peer-to-peer sync of folders between devices, with no central server	Open, private, continuous sync of folders between your own devices	One tool to copy, sync and mount files on any cloud storage
Where it is on that road	Step one, alphaA read-only share today. Works end to end in its own tests on Linux and macOS. Never released, never run in production.	MatureDecades in production. Built into every major operating system.	MatureDecades in production. Built into Windows, macOS and Linux.	MatureRuns very large production clusters. Takes a skilled team to operate.	Mature, slowingYears of production use. Development slowed after Red Hat ended its product in 2024.	Proven protocol, small toolsThe protocol is proven at huge scale. The tools that mount it as a folder are small projects.	MatureA commercial, closed-source product in wide use since 2013.	MatureOpen source, in wide use for more than ten years.	MatureOpen source, in wide use since 2012, with more than 70 storage services.
Writes	Not yetRead-only is step one. Read and write is planned.	Yes	Yes	Yes	Yes	NoRead-only, and the set of files is fixed when the torrent is made.	YesTwo-way sync.	YesTwo-way sync.	YesA mount writes through a local cache.
File locks	Not yetDistributed locks are planned.	Yes	Yes	Yes	Yes	Does not applyNothing can be changed.	NoTwo edits at once make a conflict copy.	NoTwo edits at once make a conflict copy.	NoNo locks between clients.
POSIX behavior	Reading onlyReading works like a local folder. Full POSIX behavior is the aim.	CloseClose to a local filesystem, with known gaps.	PartlyWindows rules first. POSIX extensions on Linux.	CloseClose to complete.	CloseClose to complete.	Reading onlyReading works like a local folder.	Does not applyThe files are ordinary local files.	Does not applyThe files are ordinary local files.	PartlyA mount covers the common cases, not all.
Files stay plain files	Plain filesOrdinary files in ordinary folders on each server. Nothing to import or convert; the server only reads them.	Plain filesOrdinary files on the server's own filesystem.	Plain filesOrdinary files on the server's own filesystem.	Own storageFiles are split into objects inside Ceph's own store. Data must be copied in and can only be read back through Ceph.	Mostly plainReplicated volumes keep ordinary files on each server, with extra attributes. Dispersed volumes keep encoded pieces.	Plain, plus a torrentOrdinary files at the peers, plus a torrent file that must be made from them first.	Plain filesOrdinary files in ordinary folders, plus a hidden folder for its own records.	Plain filesOrdinary files in ordinary folders, plus a hidden marker and its own index.	By serviceWhatever the storage service keeps: objects in a bucket or files on a server. Encoded only if you turn on its encryption.
Reads without a full local copy	YesStreams on demand.	Yes	Yes	Yes	Yes	YesFetches pieces on demand.	PartlySelective sync, in paid editions.	NoEvery device holds a full copy of what it syncs.	YesA mount streams on demand.
Caches what you read on local disk	Built inKeeps the blocks you read, within limits for size, age and free space. Fully cached files can be read with no server reachable.	OptionalNot by default. Linux can add a disk cache with a separate service.	Windows onlyOffline files on Windows. Not on other systems.	OptionalMemory by default. A disk cache can be added on Linux.	Memory onlyMemory caches only.	Built inKeeps the pieces it has fetched.	Does not applyIt keeps full copies, not a cache.	Does not applyIt keeps full copies, not a cache.	Built inA mount can keep what it reads, within limits for size and age.
One file read from several sources at once	YesThe one job it does today. Shown in its tests, not yet in production.	NoNot in the usual setup. Parallel NFS needs servers built for it.	NoMultichannel adds network paths to the same server.	YesInside the cluster: a file is spread over many storage daemons.	PartlyDispersed volumes read from several servers. Replicated volumes read from one.	YesFrom every peer that has the pieces.	YesFrom every device that has the file.	YesPulls blocks from several devices.	NoSeveral streams, all from one source.
A source fails during a read	ContinuesThe read continues from the other servers. Tested, not yet proven in production.	WaitsThe read waits until the server is back.	DependsThe read fails or reconnects. Failover needs a server cluster.	ContinuesThe cluster serves the data from another copy.	ContinuesThe client continues from another copy.	ContinuesThe read continues from other peers.	ContinuesThe transfer continues from other devices.	ContinuesThe transfer continues from other devices.	RetriesIt tries the same source again.
Keeps the copies in step	Not yetToday another tool must do it. Cohorts of servers, like RAID, are planned.	Does not applyThere is one copy.	NoReplication is a separate Windows service.	YesBuilt in.	YesBuilt in.	PartlyFor a fixed set of files. Any change needs a new torrent.	YesIts whole job.	YesIts whole job.	On demandWhen you run a sync.
Notices a wrong or damaged copy	PartlyCompares size, modification time and a digest of the start of each file. No checksums of the whole content yet.	Does not applyThere is one copy.	Does not applyThere is one copy.	YesChecksums on stored data and regular scrubbing.	PartlyBit-rot detection is optional.	YesEvery piece is checked against its hash.	YesEvery piece is checked against its hash.	YesEvery block is checked against its hash.	PartlyChecksums where the storage service has them.
Readers see changes to the files	YesAfter the listing cache expires, 30 seconds by default.	Yes	Yes	Yes	Yes	NoA torrent is a snapshot.	YesAfter the sync.	YesAfter the sync.	YesAfter the directory cache expires.
Choose where the data lives	Not yetPlanned for a file, a directory or a whole cluster.	Does not applyOne server.	Does not applyOne server.	YesPlacement rules by location, set per directory.	PartlyPer volume, and replication between sites.	NoWherever the peers are.	PartlyPer folder: you choose the devices.	PartlyPer folder: you choose the devices.	PartlyPer path: you choose the storage service.
Access control	BasicUsers with a password and a list of shares each. No groups, no per-file permissions, no directory service. More is the work of versions 0.x.	FullUnix permissions and ACLs. Kerberos for real user identity.	FullUsers, groups and ACLs, with Active Directory.	FullKeys limited to paths, plus Unix permissions.	FullUnix permissions and ACLs, and client address lists.	NoneAnyone who has the torrent can read it.	Per folderKeys per folder: read-only, or read and write. Users in business editions.	Per devicePer folder and device, with send-only and receive-only folders. No users.	From the serviceWhatever the storage service has.
Encryption in transit	On by defaultTLS, on by default. A new server makes its own certificate, which clients do not trust until you install a real one or put a proxy in front.	OptionalKerberos privacy, or RPC over TLS.	OptionalSMB 3 encryption.	OptionalThe secure mode of its protocol.	OptionalTLS.	WeakOptional obfuscation only, not real secrecy.	Always on	Always onTLS.	UsuallyHTTPS or SSH for most storage services.
Use across the internet	YesOne HTTPS port, directly or behind a reverse proxy.	NoNot advised without a VPN.	NoNot advised without a VPN. Port 445 is widely blocked.	NoReaders must reach every daemon of the cluster.	NoReaders must reach every storage server.	YesBuilt for it.	YesRelays and trackers get through firewalls.	YesDiscovery and relays get through firewalls.	YesBuilt for it.
Monitoring and admin tools	MinimalA status command and logs. Nothing more yet. This is the work of versions 1.x.	RichMature tools in every operating system.	RichMature tools, strongest on Windows.	RichDashboard, metrics and orchestration.	RichCommand line tools and metrics exporters.	MinimalWhatever the client program shows.	By editionThe app. A management console in business editions.	GoodWeb interface, API and metrics.	GoodStatistics, a remote control API and metrics.
Runs on	Two systemsLinux and macOS. No Windows. No FreeBSD package yet.	EverywhereEvery major operating system.	EverywhereEvery major operating system.	Mostly LinuxLinux servers. Clients for Linux and Windows.	Linux	Two systemsLinux and macOS, through FUSE.	EverywhereWindows, macOS, Linux, NAS devices and phones.	Almost everywhereWindows, macOS, Linux, BSD and Android.	EverywhereWindows, macOS, Linux and BSD.
Protocol on the wire	HTTPS: JSON listings and HTTP byte ranges	NFS over RPC, port 2049	SMB, port 445	Ceph's own protocol	Gluster's own protocol	BitTorrent, with trackers or a distributed hash table	Its own, built on BitTorrent	Its own Block Exchange Protocol, over TLS	The protocol of each storage service: S3, SFTP, WebDAV and others
What runs on the servers	One program. No database, no cluster state, no quorum	The kernel's NFS server and its helper daemons	Samba or Windows Server, often with a directory service	Monitors, managers, metadata servers and storage daemons, with a quorum	A management daemon and a process per storage folder on each server	Any BitTorrent client that seeds the files	Nothing central. The app on every device	Nothing central. Syncthing on every device	Nothing of its own. It uses the storage service

Where SpliceFS is headed

Read-only is step one. None of the following exists yet; it is what the project is building toward.

Read and writeChange files through the mount, not only read them.
CohortsGroups of servers that hold redundant copies, like RAID.
Transactional file changesA change is applied completely or not at all.
Distributed file locksLocks that hold across every server and every client.
Full POSIX behaviorPrograms see what they would see on a local disk.
Local and remote clients alikeThe same service on the local network, over the public internet or over a VPN.
Geographic tenancyChoose where data lives, for a file, a directory or a whole cluster.

The plan by version

Versions 0.xThe core of the SpliceFS protocol, and access controls.
Versions 1.xEnterprise tooling and visibility.
Versions 2.xOnly time will tell.

These are plans, not features. The 0.x line has started: its first versions are published as packages.

What is built so far

The design keeps to three aims. The grey lines say what is still missing.

Lean
- One program on each server and one on the reader.
- No database, no cluster manager, no quorum.
- The server keeps nothing about its readers.
- One server is a valid cluster.
- Today lean also means less: no writes, no replication, no locking yet.
Standard
- Everything travels over HTTPS.
- Folder listings are JSON. File contents are ordinary HTTP byte ranges.
- Every request can be repeated with curl.
- The API on top of HTTPS is its own, and it is not frozen yet.
Secure
- TLS is on from the first start.
- Passwords are stored as Argon2id hashes.
- A login gives a short-lived signed token, limited to the shares that user may read.
- The server never writes to a share.
- No outside security review yet.
- A token cannot be revoked before it expires, 30 minutes by default.

When to use something else

Today, in most cases. Use NFS or SMB for a normal shared folder. Use CephFS or GlusterFS when the storage system itself must keep copies in step. Use Syncthing or Resilio Sync to keep full copies of a folder on several devices. Use Rclone to reach cloud storage. Use BitTorrent to hand a fixed set of files to many people. SpliceFS is worth a look today only if you want to read the same live folder from several servers at once across the internet, and you can accept alpha software.