Hacker News Reader

Comment by rasz | Hacker News Reader

I envy you. All I read there was "write endurance and data retention halved again"

I have no idea why you'd read that when the cells are the same size as before.

That outcome would be expected from either decreasing cell size, or increasing bits/cell (what used to be commonly called SLC/MLC/TLC/QLC).

I don't see TFA mentioning either directly, but there are some hints that one of the two (or both) did happen: Number of layers increased from 176 to 232 (that explains 32% increase) but bits/chip area has doubled (total density increased by 100%). Where does the rest of this increase coming from, you reckon?

From a much better Anandtech article: 32% increase in layers, 40% increase in die area.

https://www.anandtech.com/show/17509/microns-232-layer-nand-...

A bunch of the cost is test and packaging which is constant so there will be a small cost per bit reduction. But the new chip will cost significantly more to manufacture than a 512Gbit device. No free lunch.

I don't see these as problems as long as software is smart enough.

It merely requires the device to be always powered up (read: has a backup battery that can do periodic flash rewrites for 5 years). And it requires the controller to keep track of the current endurance of every page. A 'worn out' page can still hold data, it just holds either less data, or holds that data for fewer hours before needing to be rewritten.

Long gone are the days of "you can rewrite this data 100,000 times, and then leave it 10 years and it'll still be there". The new normal is "rewrite this data every 20 days to begin with, and after doing 1000 writes you'll need to rewrite the data every hour, or double the ECC bits and then you'll need to rewrite every day".

It's amazing to me how you don't consider any of these major drawbacks as problems. The Samsung 840 evo was a disaster and here we are celebrating more of the same.

While I completely agree endurance can - and it is - be managed with software, rewriting data every 20 days is a major, major drawback. To me, it is a regress

We can live with DRAM. Ok. But I cannot have my computer turned off for 3 weeks though? Or I lose data?

Well the SSD should have a built in battery capable of doing whats necessary for years.

Just like your computer has a CMOS battery that's capable of running the clock for years. It's no different. In fact, many computers will refuse to boot if the clock loses time because all the digital certificates on drivers aren't valid yet.

Computer requires battery backup to remain functional. SSD requires backup battery to remain functional. I don't see the difference.

That's an extremely load-bearing "should"; are any current drives shipping like this?

The purpose of these drives is not for archive. In fact, individual SSDs in general should not be used for archiving. They are for performance. Since we're probably talking about laptops or phones typically, there's also the loss of the device or catastrophic failure (fire?) to worry about so there needs to be a disaster recovery plan regardless.

No need for any "archiving". I live in a country where you get drafted for a mandatory army service once you reach 18 years of age. The user leaves his desktop (or laptop) at home, goes to the army, returns back in a year, and — whoops — there's no data left on the drive. You know the user should have kept backups, and I know that, but your average Joe is going to be pretty unpleasantly surprised.

Thats why the drive should have a battery backup builtin lasting many years...

Years of battery life isn't tricky, because the drive can, upon being unpowered for a week, rewrite data to be more durable at the expense of access time. 'recovery blocks' can be created which allow the recovery of any unreadable block on the drive. The drive can then wake up and rewrite data only as often as needed based on temperature and the error rate found on the last rewrite. For example, on a 1TB SSD, you might only rewrite 5GB/day, taking just 10 seconds at 1 watt. On a 5 Wh battery, thats 5 years. And thats a worst case - keep it somewhere cool, and the rewrite rate might be halved, doubling battery life. Have the drive half full, and the battery life is doubled again (due to half as much to rewrite), and multiplied by 8 (due to the ability to use the spare space for ECC data). So a half full drive stored in a cool place might be able to last 160 years. Obviously at that point, the battery self discharge and power to run timers will dominate.

>or double the ECC bits

Are you aware of even a single ssd product allowing user to reconfigure capacity outside of obtaining secret/proprietary non public manufacturer service software? The only technical way for a drive to automagically shrink size on its own is by starting to mark TRIM freed sectors as BAD and hoping OS running on top will be able to recognize this and transfer BAD status to the filesystem - thats a lot of assumptions. No such drive exists either, drives ship with spare capacity and existence of BAD sectors is treated as a catastrophic event signaling running out of backup NAND.

You can use hdparm(8)'s --dco-setmax option to reduce the visible size of most SATA drives. This is not particularly useful for single drives — leaving unpartitioned space works just as well, assuming an OS that never writes to it — but it does stop TRIM-ignorant RAID controllers from potentially kneecapping SSD GC by "initializing" intentionally unused space.

Though I imagine most RAID controllers initialize with zeroes, and I hope SSD firmware doesn't reserve flash to store large extents of zeroed sectors, so this shouldn't be terribly useful for underprovisioning purposes. But without extensive testing or access to SSD firmware algorithms, it's hard to say.

This is one layer too high - ssd firmware has no way of knowing your intentions purely from filesystem/sector activity.

Drives internally do this with their reserved sectors. They also reallocate sectors between 'fast access' and 'long term storage', where the long term storage uses larger logical pages and hierarchical ECC, allowing a lower percentage of ECC overhead at the cost of performance.

At some point, I wouldn't be surprised if an SSD manufacturer releases a drive with a driver which can reduce the user-visible disk size as it ages. It would probably involve using a 'balloon file', in a similar way to Memory ballooning [1]

[1]: https://en.wikipedia.org/wiki/Memory_ballooning

Intel SSD DC series https://www.ioncomputer.com/ion/body/documents/over-provisio...

On SAS disks you can reduce the capacity. I don't know if this has any influence on spare sectors and write cycles though.

You can reserve space by setting host protected area (HPA). There are even people theorizing this might add provisioning are to an SSD https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_u... . But so far there is zero evidence for it. HPA is not a magic nobody touches area, its an area reserved for special superuser use and no Drive will simply start reusing it for its own internal processes.

Reply on news.ycombinator.com