ltfs

Reference implementation of the LTFS format Spec for stand alone tape drive

Systems & Infrastructure Learning & Reference

Explore on GitHub Read Hacker News discussions

4Distinct people

4Mentions

0Explicit recommenders

366GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Reference implementation of the LTFS format Spec for stand alone tape drive

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2022-01-27 13:12:19 UTC to 2026-05-11 07:22:44 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	2	2
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	0	0
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	2	2

What Hacker News says

4 sources

cyberax·May 11, 2026

I'm playing with a tape drive for backups, so I asked a local model to rewrite LTFS ( https://github.com/LinearTapeFileSystem/ltfs ) in Go. I gave it the reference C implementation, the LTFS spec from SNIA, and asked it to use the C implementation to verify the correctness of the Go code. LTFS is a pretty straightforward spec, so it made a very reasonable port within about 2 days. It's now working on implementing the iSCSI initiator (client) to speak with my tape drive directly, without involving the kernel. Edit: the model is Qwen3.6-35B

In Local AI needs to be the norm

Fnoord·Mar 17, 2026

Standardization [1] for backups. A tape with 2.5 TB (uncompressed) goes for 30 EUR. The LTO-6 (affordable current iteration) drive itself goes for 300-500 EUR if you buy it second hand. Cheaper if you grab one without casing and FC, but you'd need a FC switch and a FC HBA. I went for a SAS HBA instead, although since I already for fiber through the whole house, FC would've been suffice. [1] https://github.com/LinearTapeFileSystem/ltfs

In Why I love FreeBSD

connorgutman·Jan 27, 2022

I recently purchased a LTO-5 drive for my Gentoo-based NAS and have a few key takeaways for those who are interested. Don't buy a HP tape drive if you want to use LTFS on Linux! HPE Library & Tape Tools is prety much dead on modern Linux. Official support is only for RHE 7.x and a few versions of Suse. Building from source is a dependency nightmare that will leave you pulling hair. IBM drives have much better Linux support thanks to https://github.com/LinearTapeFileSystem/ltfs. That being said, IMO, you should consider ditching LTFS for good ol' TAR! It's been battle tested since 1979 and can be installed on basically anything. TAR is easy to use, well documented, and makes way more sense for linear filesystems. While drag&drop is nice and all, it really does not make sense for linear storage.

In LTO Tape data storage for Linux nerds

c0l0·Jan 27, 2022

I recently started looking into using an LTO-7 tape drive that I got handed down, along with a few dozens of pristine LOT-6 tapes, for archiving purposes. I got to play around a bit with SAS HBAs, and was kinda shocked how much of a difference that can make in the user (or shall I say sysadmin?) experience: LTO-6 tapes are spec'd to transfer rates of around 150MB/s, so well within the reach of even the the first SAS gear generation. However, the very first SAS HBA with external SFF-8088 connector I managed to get my hands on (an LSI SAS1068e) topped out at a disappointing 80MiB/s, no matter what I tried in terms of blocking and buffering. Switching to a more modern (but still old) LSI SAS2008-based HBA got me close to the theoretical maximum. Then there's the (to me, still open) question of how to best use the actual tape storage capactiy

Read the rest

... Since my hardware is newer than LTO-5, LTFS (https://github.com/LinearTapeFileSystem/ltfs) is an option for convenient access, especially listing tape contents, but that could make it hard for other people down the line to restore data from the tapes I create. It's probably safest to assume that tar will always be there, at least wherever there's tape, too. GNU tar also handles multi-volume/-tape archives, which seems like a necessity if you need to back up amounts of data that exceed a single tape's capacity. Then again, if you want to use encryption with actual tar (important for the kind of data I need to archive), your only option seems to be piping the whole archive through something to compress the stream, which will make accessing individual records in the archive opaque to the drive itself... and you can't just dispose of individual keys to make select parts of the archived data go away for good, either. Also, I would like to conserve as much tape as (conveniently) possible in my archiving adventure. There's "projects" (i.e., top-level directories of directory trees) that consume more than one tape of their own, and then there's smaller projects that you can bin-pack together onto tapes that can fit more than one such project. I've started implementing a small python wrapper around GNU tar to solve a number of these problems by bin-packing projects into "tape slots" and also keeping track of tape-to-file mappings in a small sqlite database, but a workable solution for the encryption problem(s) is not something I managed to come up with yet... If someone has an idea (or better yet, a complete and free implementation of what I am trying to hack together :)), please be so kind and let me know!

In LTO Tape data storage for Linux nerds