LTFS — the Linear Tape File System — has been marketed heavily, promising the low per-gigabyte cost of tape with the plug-and-play convenience of a USB drive. It is a compelling pitch, and for some use cases, such as sharing large datasets between organizations, LTFS is an understandable choice. For production workflows and long-term archiving, we do not recommend it. This page explains why.
Hard disks are random-access devices. A filesystem can read and update file metadata — names, paths, sizes, dates — anywhere on the disk at any time, which is why filesystems sit so naturally on them.
Tape is a sequential-access device. Data is written as a stream of blocks, one after another. LTFS makes tape emulate a random-access device by splitting each cartridge into two partitions that run side by side along the length of the tape: one for data, and one for a metadata index that is rewritten every time the tape is used. LTFS was specified in 2010 by the LTO Consortium — the drive manufacturers — on the promise of tape that behaves like a pen drive; a block-based format would have been simpler to specify and better suited to the medium, but it was not the format that was standardized.
The deeper mismatch is in what a filesystem is for. A filesystem manages a space that changes: files are created, grow, shrink, and are deleted; the holes left by deleted data must be found and reused; free space must be tracked and fragmentation kept under control. All of that machinery exists to make mutable storage efficient.
An archive needs none of it. Archival data is written once and never deleted, so the workload is simply stacking objects in an orderly line, one after another — and sequential media is ideally suited to exactly that. LTFS carries the machinery of a mutable filesystem onto a workload that has no use for it.
That emulation is complex, and complexity in a storage format translates directly into risk. Our policy on this is simple: the simpler the storage format, the easier data recovery will be — under any circumstances.
TAR — the tape archive format — predates LTFS by decades and is available by default on every Linux and Unix-like system. Any tar writes files back-to-back on tape with simple header blocks between them: no filesystem, no mounting, no index to keep synchronized — nothing on the tape but the files themselves, appended one after another. Tar has accumulated several dialects over its long life, so for standardization we use the POSIX-specified pax form (POSIX 1003.1-2001) — one precisely defined variant that any modern tar reads.
| Aspect | TAR | LTFS |
|---|---|---|
| Open specification | Yes (POSIX) | Yes (SNIA LTFS Format) |
| Format complexity | Low | High |
| Corruption risk | Low | High |
| Mount/unmount overhead | None | ~45 s each way measured; vendor docs allow minutes |
| Usable tape capacity | ~98% | ≈95% structural; ~88% in our measured use |
| Self-describing tapes | Achievable (see below) | Yes, natively |
| Partial file retrieval | Yes | Yes |
| Software needed to read a tape | tar — a standard tool on every Linux and Unix-like system | Vendor or third-party LTFS application, installed separately |
Third-party corroboration: HPE's StoreOpen best-practices guide notes that large indexes lead to "an extended delay in mounting the file system" (≈1 kB of index per file); Fujitsu's LTFS guide allows about ten minutes for background processing at eject; Quantum's StorNext documentation advises against LTFS for the retrieval copy. On capacity, the index partition and its guard wraps consume about 5% structurally (≈75 GB on LTO-5), before index growth in the data partition; tools such as YoYotta additionally reserve ~100 GB of headroom.
Every LTFS tape must be mounted before use and cleanly unmounted afterward, so the index partition can be read and updated. If a tape is removed, or the drive loses power, before unmounting completes, the volume can be left in an inconsistent state. Anyone who has pulled a pen drive out without ejecting it first, and found it corrupted afterwards, has met this failure. LTFS is marketed as tape that behaves like a pen drive — and in this respect it does.
This is not theoretical — it is in the vendors' own documentation. From the Quantum LTFS User Guide:
"Tape activity may continue for several minutes after un-mounting an LTFS volume… Attempting these actions before tape activity has finished may cause corruption of the tape format."
And on power loss:
"…if power is removed from the drive without unmounting… the volume will be left in an inconsistent state and all files added since the last dismount operation will be inaccessible. The ltfsck utility may be able to recover the file data… but the metadata (such as filename, access dates) will be lost."
Note the second half of that: recovery may restore your data, but stripped of its filenames and dates — which, for an archive, is often a marginal recovery at best.
Vendor mitigations — periodic index writes, write-on-close index updates — reduce the exposure window, but they add capacity and performance overhead, and they cannot remove the underlying fragility of maintaining a filesystem on sequential media.
TAR has essentially none of this risk. If power fails mid-write, you seek back to the last valid header block and rewrite from there. No recovery utility required.
In our experience, mounting and unmounting an LTFS tape takes 30–60 seconds each way, and vendor documentation acknowledges it can take several minutes. Every tape load/unload cycle therefore costs roughly 90 seconds of drive time that TAR simply does not have.
For a single tape that may be inconsequential. At production scale it is not. In one representative month, our restore requests touched an average of 30 different tapes per day — roughly 45 minutes of drive time lost daily, every day, just to mounting and unmounting. Quantum's own StorNext documentation advises against configuring LTFS for the copy used for file retrieval.
The LTFS index partition consumes tape capacity. Officially around 5%; in our experience it has reached as high as 20%, and we model it at an average of 12.5%. The gap between the official figure and the observed one has a mechanism: the index is not only kept in its own partition but is also written again into the data partition at syncs and at unmount. Through format 2.4 each of those writes was a complete copy of the index, so consumption grew with the number of files and the number of sessions — these are the versions behind our measurements. Format 2.5 (2019) added incremental indexes that record only changes, which reduces this growth on implementations that use them. TAR's metadata overhead, by contrast, is negligible — about 2% including a safety buffer.
LTFS is an open standard on paper. In practice, reading an LTFS tape usually means installing a vendor or third-party application, and we have hit real friction:
A TAR tape, by contrast, can be read on any Linux machine with no additional software. When the goal is guaranteed access to archived data decades from now, that matters.
LTFS also omits the parts an archive actually needs. It records no per-file checksums, so it cannot tell you whether what came back is what went in. It provides no parity, so a damaged cartridge is a matter of luck.
Both can be added through a vendor's own metadata — but a standard LTFS reader will ignore it, and an archive that needs a particular vendor's software to interpret its integrity data has arrived back at the problem LTFS was introduced to solve.
If your workflow involves routinely shipping tapes to outside parties, LTFS is a reasonable choice. Our workflow is fully in-house — tapes are written and read by a single system — so these advantages do not offset the risks for us.
TAR's one genuine gap is that it is not natively self-describing. The gap is closable, and closing it is simpler than adopting a filesystem. For years our production archive did it the plain way: a full catalog of the tape's contents appended at the end — the logical equivalent of the LTFS index, without the mutable filesystem underneath. Even with the archive database lost, every tape could describe itself.
The REM formats are the evolution and formalization of that idea. Every REM-OBJECT carries a manifest recording each file's path, size, checksum, and position; REM-PARITY adds repeating bootstrap blocks along the cartridge, so a bare, unlabelled tape can be mapped, verified, and repaired from the tape alone. Tar's simplicity is kept; LTFS's one real advantage is matched.
LTFS's self-describing index does not eliminate the need for a database in practice — any archiving application still needs one for cross-tape search.
Tape is a sequential medium, and formats that naturally align with that fact are simpler, safer, and cheaper to operate.
Data integrity deserves the same discipline whatever the format: neither TAR nor LTFS provides built-in write-time integrity checking. Our practice is to calculate a checksum for every file, store it outside the tape, and verify it — including a full restore and re-checksum of every archive we write.