this post was submitted on 14 Dec 2025
449 points (97.5% liked)
Technology
77694 readers
2742 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I wonder what the read write speed is. Imagine storing your entire movie collection in a crystal the size of a coaster.
Might not be for home consumers anytime soon, article says: “In the next 18 months, the company hopes to have a field-deployable read device that customers can use to read archived data. But SPhotonix isn't presently targeting the consumer market. Kazansky estimates that the initial cost of the read device will be about $6,000 and the initial cost of the write device will be about $30,000.”
Then goes on to mention they need about 3-4 years of R&D so they can be ready to license the tech
In case you missed it in the article, the transfer speeds are mentioned just two paragraphs prior to the one you cited:
Writing 360 TB at 4 MB/s will take over 1000 days, almost 3 years. Retrieving 360 TB at a rate of 30 MB/s is about 138 days. That capacity to bitrate ratio that is going to be really hard to use in a practical way, and it'll be critical to get that speed up. Their target of 500 MB/s is still more than 8 days to read or write the data from one storage platter.
One counterpoint - even with a weak speed to capacity ratio it could be very useful to have a lot of storage for incremental backup solutions, where you have a small index to check what needs to be backed up, only need to write new/modified data, and when restoring you only need to read the indexes and the amount you're actually restoring. This saves time writing the data and lets you keep access to historical versions.
There's two caveats here, of course, assuming those are not rewritable. One, you need to be able to quickly seek to the latest index, which can't reliably be at the start, and two, you need a format that works without rewriting any data, possibly with a footer (like tar or zip, forgot which one), which introduces extra complexity (though I foresee a potential trick where the previous index can leave an unallocated block of data to write the address of the next index, to be written later)