How does this work at a physical level?

Posted Feb 23, 2025 2:37 UTC (Sun) by KJ7RRV (subscriber, #153595)
Parent article: Support for atomic block writes in 6.13

How is an atomic write possible on physical media? Since writing data has to happen at a finite rate, thus taking nonzero time, isn't there always the possibility of abruptly losing power halfway through the write?

How does this work at a physical level?

Posted Feb 23, 2025 4:35 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

A capacitor can store enough charge to power the chip long enough to finish writing.

How does this work at a physical level?

Posted Feb 23, 2025 7:25 UTC (Sun) by KJ7RRV (subscriber, #153595) [Link] (4 responses)

That makes sense; thank you! So the drive has to be built with a capacitor to enable this feature?

How does this work at a physical level?

Posted Feb 23, 2025 13:01 UTC (Sun) by farnz (subscriber, #17727) [Link] (2 responses)

It doesn't need a capacitor, necessarily. There's two routes you can take in an SSD to enable this feature:

Have a capacitor or other energy store on the device, so that when power is lost, you can complete all the writes before the energy store drains.
Use the FTL's block mapping to allow you to atomically switch in a new mapping with a single bit write, and do not return that the command is complete until the new mapping is switched in. Then, you can write the new data and associated mapping, followed by the single bit write to switch the mapping over. If that bit write succeeds, the swap over is done; if it doesn't, the swap fails to happen.

Capacitor is more likely, because it lets you have a write cache, too, and thus a performance advantage in enterprise drives. But it's possible without one in an SSD.

How does this work at a physical level?

Posted Feb 24, 2025 1:32 UTC (Mon) by Paf (subscriber, #91811) [Link] (1 responses)

"Use the FTL's block mapping to allow you to atomically switch in a new mapping with a single bit write, and do not return that the command is complete until the new mapping is switched in. Then, you can write the new data and associated mapping, followed by the single bit write to switch the mapping over. If that bit write succeeds, the swap over is done; if it doesn't, the swap fails to happen."

I like that this is basically double writes - sometimes, it's turtles all the way down.

How does this work at a physical level?

Posted Mar 3, 2025 17:09 UTC (Mon) by mebrown (subscriber, #7960) [Link]

No, it's not a double write.

The new data is written to a new block, then the mapping table entry is atomically switched so that the old data is unmapped/freed and the new data is swapped in.

How does this work at a physical level?

Posted Feb 23, 2025 13:50 UTC (Sun) by kleptog (subscriber, #1183) [Link]

For non-SSDs you have hardware RAID controllers with a battery-backed memory that will hold the blocks waiting to be written and if the power fails it will keep the data and write it out when the power comes back.

How does this work at a physical level?

Posted Mar 6, 2025 8:32 UTC (Thu) by ras (subscriber, #33059) [Link] (1 responses)

Spinning Rust has always had to solve this problem so some extent. You can't have a 1/2 written block causing disk errors, so they ensured they had enough power around to complete writing a sector once it started. I'm not sure how they did it. One explanation I heard was they used rotating power in the platters. Extending that time with a super capacitor wouldn't be a big change.

How does this work at a physical level?

Posted Mar 18, 2025 18:20 UTC (Tue) by sammythesnake (guest, #17693) [Link]

With transfer speeds of GiB/s (or even MiB/s if we're talking about the Good Old Days) a 4KiB sector will take bugger all time to write, so a supercap is colossal overkill for "finish the sector" power. Flushing the whole of a sizeable cache would likely be into the realm of a non-super capacitor, though, especially in the pathological case of the cached writes all being single sectors nowhere near each other...