LTFS compared with tar and the REM formats.

The first problem, legibility, tar had already solved. POSIX tar is published, decades old, and read by a tool already installed on every Unix-like system, so an archive written as tar was never exposed to the proprietary-format failure.

The second problem, location, both formats solve, by different means. LTFS keeps a filesystem index in its own partition, updated as the cartridge is used. Remanence writes a manifest into every object, listing each file's path, size, checksum, and position, and writes the complete tape map three times at the end of the tape when the cartridge is finalized. One surviving copy avoids a scan of the whole reel.

Which mechanism is better depends on who is doing the reading. For a person at a single drive, LTFS is the better model. Once mounted, the cartridge is a filesystem: they can list it, browse it, and copy a file out with the tools already on the machine, with nothing to install or learn. For software the same presentation is overhead. A scheduler picks the cartridge and a program extracts a known byte range; all it needs is an offset and a length, which a manifest gives it directly. The mount and unmount still has to happen on every cartridge, and its cost is measured further down. Our own archive runs this way almost entirely, and as more archive work is done by software rather than by hand, the filesystem view matters less than it once did.

The third problem is survival. Media degrade, and in a library of any size some cartridges develop blocks the drive cannot read well before their rated life is out. LTFS assumes a conforming implementation is available and the medium reads back correctly, which is reasonable for a format whose purpose is interchange. It records no per-file checksums and provides no parity. Neither belongs to the problem it set out to solve; an interchange format has no business dictating an institution's fixity strategy. For a preservation workflow those controls still have to come from somewhere, so with LTFS they are supplied by the layer above: a checksum manifest in a database, a second copy, a validation script after every write. That scaffolding works, but it lives outside the format and outside the cartridge.

The REM formats move those controls into the format. REM-OBJECT carries a SHA-256 for every file, so what comes back can be shown to be what went in. REM-PARITY adds Reed–Solomon parity stored apart from the data, so unreadable blocks are rebuilt from the surviving ones. A cartridge separated from its institution can then still prove what it holds. Whether that is worth its cost depends on whether an archive expects to outlive its software and to meet degraded media. Many working archives reasonably conclude that it is not. What follows is the detail behind our own conclusion, with the measurements and the vendor documentation.

One distinction runs through this page: the LTFS specification, a vendor's implementation of it, and the workflow built around it are three different things. Several of the difficulties below belong to the second and third rather than the first, and each section says which.

A hard disk is a random-access device. A filesystem can read and update file metadata anywhere on it at any time, which is why filesystems sit so naturally on disks. Tape is sequential. Data is written as a stream of blocks, one after another. LTFS presents a random-access view of that medium by splitting each cartridge into two partitions running side by side along its length, one for data and one for a metadata index that is rewritten as the tape is used.

That presentation has a cost, because a filesystem is machinery for a space that changes. Files are created, renamed, overwritten, and deleted, and the index has to be kept consistent with the data through every one of those changes. On tape LTFS does this by rewriting the index in its second partition as the cartridge is used. The data partition underneath is still only ever appended to, and the space of a deleted file is not reclaimed, but the index that describes it is mutable state that must be kept in step. An archive needs almost none of that. Archival data is written once and not deleted, so the workload is stacking objects end to end, which is what sequential media do well. The simpler the on-tape structure, the fewer states it can be left in, and the easier recovery is when something goes wrong.

Tar, the tape archive format, predates LTFS by decades. It writes a single stream: a short header, then the file's bytes, file after file, with no filesystem, no mount, and no index to keep in step. Tar has accumulated dialects over its life, so the REM formats use the POSIX-specified pax form (IEEE 1003.1-2001), one precisely defined variant that every modern tar reads.

Aspect	Tar	LTFS	REM formats
Designed for	Streaming files to sequential media	Interchange: a cartridge readable without the writing application	Automated archives that must survive lost catalogs and partial damage
Open specification	Yes (POSIX)	Yes (SNIA LTFS Format, ISO/IEC 20919)	Yes, as public review drafts
On-tape structure	One append-only stream	Two partitions; an index updated as the cartridge is used	One append-only stream, plus parity, a bootstrap, and three copies of the index
Mount and unmount	None	30–60 s each way measured; vendor documents allow minutes	None
Usable capacity	About 98%	About 95% structurally; 80–88% in our measured use	About 98% for large files, less the parity level chosen; small files also pay for alignment, since each starts on a 256 KiB to 1 MiB boundary
Self-describing tape	Achievable (see below)	Yes, natively	Yes once finalized: a manifest in every object and three copies of the index
Per-file checksums	No	No	Yes, SHA-256
Damage recovery	No	No	Yes, Reed–Solomon parity stored apart from the data
Partial file retrieval	Yes	Yes	Yes, any byte range, by arithmetic
Software needed to read a tape	tar, standard on every Unix-like system	A vendor or third-party LTFS application, installed separately	Standard tar for the files; open-specification tools to verify and repair

Third-party corroboration: HPE's StoreOpen best-practices guide notes that large indexes lead to "an extended delay in mounting the file system" (about 1 kB of index per file); Fujitsu's LTFS guide allows about ten minutes for background processing at eject. On capacity, the index partition and the guard bands around it consume about 5% structurally (about 75 GB on LTO-5), before index growth in the data partition; tools such as YoYotta additionally reserve around 100 GB of headroom.

An LTFS tape is mounted before use and unmounted afterward so that the index can be read and updated. If a cartridge is removed, or the drive loses power, before unmounting completes, the volume can be left inconsistent. That is the ordinary consequence of keeping mutable state on the medium, and the vendors document it. From the Quantum LTFS User's 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."

The second half of that passage is what mattered to us. Recovery may restore the data, but without filenames and dates, and for an archive whose descriptive metadata is much of its value that is a partial recovery. Implementations reduce the exposure with periodic index writes, and a workflow that unmounts promptly will rarely meet the failure. Our requirement was to remove the exposure rather than manage it. With tar, an interrupted write is repaired by seeking back to the last valid header and continuing from there, with no recovery utility involved. The REM formats inherit that: an interrupted write costs at most the object in flight, never the volume.

Mounting and unmounting an LTFS cartridge takes time, because the index must be read and then written back. In our measurements it was 30 to 60 seconds each way, and vendor documentation allows for several minutes. A tar tape has no equivalent step. Whether that matters depends on scale. For an archive whose cartridges are mounted occasionally it is irrelevant. In one representative month our restore requests touched dozens of different tapes a day, and the mount and unmount cycles alone would have cost the better part of an hour of drive time daily. Quantum's StorNext documentation advises against configuring LTFS for the copy used for file retrieval, which is consistent with what we measured.

The index partition also consumes capacity. The structural cost is about 5%. In our measured use the total ran between 12% and 20%, because the index is not only kept in its own partition but is also written again into the data partition at each sync and unmount. Through LTFS format 2.4 each of those writes was a complete copy, so consumption grew with the number of files and sessions; those are the versions behind our measurements. Format 2.5, from 2019, added incremental indexes that record only changes, which reduces the growth on implementations that use them. Tar's metadata overhead is about 2%, including a safety margin.

LTFS is an open standard with an open-source reference implementation. The friction we met was in products and packaging rather than in the specification. Some vendor LTFS tools check the manufacturer of the attached drive and decline to work with another vendor's hardware; on one occasion we compiled the reference implementation from source in order to read LTFS tapes written by a third-party archiving application. The specification has also been revised over time, and a cartridge written under a newer revision may not be readable by an older implementation. That is normal for a maintained standard and manageable when the reading environment is known. It is harder to reason about across several migration cycles. A tar tape can be read on any Unix-like system with a tool that is already there, and that was one of our reasons for choosing it.

One dependency neither format removes is the drive. Since LTO-8 a drive reads only its own generation and the one before it; earlier generations read two back. A cartridge outside that window cannot be read at all, whatever is written on it. So the practical horizon for any tape format is the migration cycle, typically several years, rather than the life of the medium. A tape left longer than that becomes unreadable for want of a drive, whatever its format. So the formats are designed for each cartridge to be read and copied forward within its window, and for the archive, rather than any one cartridge, to remain readable across those cycles. When this site speaks of thirty years it means the data and the format carried across several generations of media, not a single tape left on a shelf. Migration is also when the format matters most: every tape is read end to end, any bad patch surfaces then, and a per-file checksum is what shows the new copy is faithful.

Tar's one real gap is that it is not self-describing. Closing it costs one extra write. For years our production archive appended a full catalog of the tape's contents at the end of each cartridge when it was finalized: the logical equivalent of the LTFS index, written once, with no second partition, no mount cycle, and nothing rewritten as the tape was used. Even with the archive database lost, every tape could describe itself.

The REM formats formalize that practice. The catalog moves inside each object as a manifest, and finalization writes the complete tape map three times, physically separated, at the end. Any one surviving copy lets a bare unlabelled tape be mapped, verified, and repaired from the tape alone.

An LTFS index on the cartridge does not remove the need for a database in practice either. Any archiving application still needs one to search across tapes.

The choice follows from what an archive has to survive.

Where cartridges leave the building, for interchange with another institution, delivery to a client, or a colleague with a standalone drive and no relationship to your system, LTFS is doing the job it was designed for. A published filesystem view means the recipient needs nothing from you but the cartridge.

Where the archive is written and read by one automated system, and the requirement is to reconstruct and prove its contents after the catalog and the software are gone, we chose the tar family. Plain tar is simple, open, and readable with tools already present. The REM formats keep that base and add per-file checksums, parity, and catalog-free recovery.

Whichever format you choose, do not put every copy in it. Implementation defects have shipped in tape software of every kind, and ours is not exempt. If every copy of an archive shares one format, one format-level defect can reach all of them at once. Fixity needs the same discipline in either case. Neither tar nor LTFS checks integrity at write time on its own, and our practice has been to checksum every file, store the checksum away from the tape, and verify it, including a full restore and re-checksum of every archive we write.