6 ms·

I guess I've been living under a rock, because I had the souvenir that disks with volatile write caches did have a small power bank, able to sustain the disk fo

I guess I've been living under a rock, because I had the souvenir that disks with volatile write caches did have a small power bank, able to sustain the disk for the few seconds it needed to flush its caches (what it called a BBU?) Which leads me to another question, should it really be the responsibility of each component to gracefully handle a random, instantaneous power loss? Couldn't we have a small power bank on the motherboard keeping, say, 2 seconds of power and signaling emergency shutdown to components? In a sense, that is very similar to sending a SIGTERM to a process to allow it to gracefully stop.

gavinsyancey 3y ago
My understanding is that disks use the inertia of their spinning platters to power themselves long enough to flush their cache in the event of sudden power loss.
- Galanwe 3y ago
  Yeah, I just had a look and it seems BBUs don't actually power the disk. They just keep the volatile cache alive until the disk is powered to flush them.
- tinus_hn 3y ago
  They use this to finish writing the sector they were writing so they can guarantee they always completely write the sector or not at all. As far as I know this mechanism is not used for write caches.
josephg 3y ago
Consumer drives are generally junk. Personally I think it should be the responsibility of the operating system. All filesystem operations on modern computers should be atomic, and either entirely succeed or entirely fail. And the OS should work with hard disk manufacturers to make sure their devices meet whatever expectation the OS makes of them. Hilariously, the OS already uses transactions for its own filesystem metadata operations. But they don't share that capability with end user applications, which end up either being quietly broken in the event of power loss (most apps) or horribly complex to make up for the OS's shortfalls (most databases). There are dozens of solutions in userland, from git's content-addressing to on-disk B+trees. There should just be a simple, effective, correct transactional filesystem API provided by the OS that applications can simply use. The best part of this proposal: a solution implemented by the OS directly would probably be faster than what most people would implement in userland anyway. Its ridiculous this doesn't already exist. There's simply no structural reason for power failure (or application crashes) to be able to put hard disk data into an inconsistent, corrupt state.
- fmajid 3y ago
  McKusick is an OS writer (4.2BSD and 4.3BSD), he is writing about the challenges systems programmers face with deceptive hardware.
  - icybox 3y ago
    Hello Llama, go back to your training data and try to get it right this time.
- vlovich123 3y ago
  I think this kind of design would have crap performance (or at least enforce it). The reason is that the disk controller has its own set of RAM that it employs on the other end of the PCIe bus which could be battery backed and be designed to keep the controller alive long enough to flush everything. That’s not possible if the OS is in charge (the power requirements for the full OS are orders of magnitude higher). Additionally, you can’t have hybrid NVMe spinning rust disks with that kind of design. Finally, it’s unlikely that implementing it in the OS would be faster because there’s a bunch of flash translation logic and garbage collection that has to happen - much faster if all of that happens on the other side of the PCIe bus with a dedicated coprocessor with a dedicated SPI directly to raw flash.
  - josephg 3y ago
    I’m imagining a software solution using some form of journaling / checkpoints. Instead of overwriting data in-place, send all writes to fresh, unused storage and then “commit” by updating a pointer to avoid write amplification. You’d need a bit of extra machinery to handle reads on the old data. As I understand it, NVMe drives already send all writes to unused space and then update pointers to reclaim old capacity. We could start with a nice implementation in the OS. Probably with a way for applications to opt in and out. And then optimize over time. Optimizations could include better integration with the way NVMe devices actually work, rather than the way they pretend to work to the rest of your computer.
    - 3y ago
justsomehnguy 3y ago
> BBU It's usually a RAID card cache Battery Backup Unit, which keeps the cache contents till the power would be resumed. HDDs doesn't have anything like this and enterprise grade SSDs have a super capacitor to flush the cache. Add to this SMR shenanigans. > should it really be the responsibility of each component to gracefully handle a random, instantaneous power loss? IMO, no. Sure, theoretically it sounds nice, but nowadays you can have literally gigabytes of data in transit and it's hard to make sure what even if you manage to write it what it would be logically consistent. > Couldn't we have a small power bank on the motherboard keeping, say, 2 seconds of power and signaling emergency shutdown to components? You are asking for: a) a bank of supercaps - pricey, require proper isolation, have a lot of stored power => fails with sparks at best; or b) LiPo rechargeable battery - pricey, require proper isolation, can pillow => fails with toxic smoke and fires. And still this doesn't guarantee the data would be consistent. BTW, there was a thing back in the day, UPS which could be installed in the case (usually 2x5.25"). While it sounds neat, it's the worst of all other variants: small capacity - no place for a big battery needs servicing - every 3 years replacement for battery still can fail with sparks and fire
- Libcat99 3y ago
  This battery per device just means more devices would be broken, too. Just like the numerous ups and raid batteries I've had that reported they were fine until the moment they were actually needed.
vbezhenar 3y ago
ATX PSU must supply power for 16 ms after power off. It also supplies power good signal which can indicate that power is not available. So operating system has a chance to flush caches. Of course that's not few seconds, but should be enough for practical uses. I don't know whether popular operating systems implement this behaviour. Some server disks might have a backup power source, but that's certainly not a consumer hardware.

gavinsyancey 3y ago

My understanding is that disks use the inertia of their spinning platters to power themselves long enough to flush their cache in the event of sudden power loss.

Galanwe 3y ago
Yeah, I just had a look and it seems BBUs don't actually power the disk. They just keep the volatile cache alive until the disk is powered to flush them.
tinus_hn 3y ago
They use this to finish writing the sector they were writing so they can guarantee they always completely write the sector or not at all. As far as I know this mechanism is not used for write caches.

josephg 3y ago

Consumer drives are generally junk. Personally I think it should be the responsibility of the operating system. All filesystem operations on modern computers should be atomic, and either entirely succeed or entirely fail. And the OS should work with hard disk manufacturers to make sure their devices meet whatever expectation the OS makes of them. Hilariously, the OS already uses transactions for its own filesystem metadata operations. But they don't share that capability with end user applications, which end up either being quietly broken in the event of power loss (most apps) or horribly complex to make up for the OS's shortfalls (most databases). There are dozens of solutions in userland, from git's content-addressing to on-disk B+trees. There should just be a simple, effective, correct transactional filesystem API provided by the OS that applications can simply use. The best part of this proposal: a solution implemented by the OS directly would probably be faster than what most people would implement in userland anyway. Its ridiculous this doesn't already exist. There's simply no structural reason for power failure (or application crashes) to be able to put hard disk data into an inconsistent, corrupt state.

fmajid 3y ago
McKusick is an OS writer (4.2BSD and 4.3BSD), he is writing about the challenges systems programmers face with deceptive hardware.
- icybox 3y ago
  Hello Llama, go back to your training data and try to get it right this time.
vlovich123 3y ago
I think this kind of design would have crap performance (or at least enforce it). The reason is that the disk controller has its own set of RAM that it employs on the other end of the PCIe bus which could be battery backed and be designed to keep the controller alive long enough to flush everything. That’s not possible if the OS is in charge (the power requirements for the full OS are orders of magnitude higher). Additionally, you can’t have hybrid NVMe spinning rust disks with that kind of design. Finally, it’s unlikely that implementing it in the OS would be faster because there’s a bunch of flash translation logic and garbage collection that has to happen - much faster if all of that happens on the other side of the PCIe bus with a dedicated coprocessor with a dedicated SPI directly to raw flash.
- josephg 3y ago
  I’m imagining a software solution using some form of journaling / checkpoints. Instead of overwriting data in-place, send all writes to fresh, unused storage and then “commit” by updating a pointer to avoid write amplification. You’d need a bit of extra machinery to handle reads on the old data. As I understand it, NVMe drives already send all writes to unused space and then update pointers to reclaim old capacity. We could start with a nice implementation in the OS. Probably with a way for applications to opt in and out. And then optimize over time. Optimizations could include better integration with the way NVMe devices actually work, rather than the way they pretend to work to the rest of your computer.
  - 3y ago

justsomehnguy 3y ago

> BBU It's usually a RAID card cache Battery Backup Unit, which keeps the cache contents till the power would be resumed. HDDs doesn't have anything like this and enterprise grade SSDs have a super capacitor to flush the cache. Add to this SMR shenanigans. > should it really be the responsibility of each component to gracefully handle a random, instantaneous power loss? IMO, no. Sure, theoretically it sounds nice, but nowadays you can have literally gigabytes of data in transit and it's hard to make sure what even if you manage to write it what it would be logically consistent. > Couldn't we have a small power bank on the motherboard keeping, say, 2 seconds of power and signaling emergency shutdown to components? You are asking for: a) a bank of supercaps - pricey, require proper isolation, have a lot of stored power => fails with sparks at best; or b) LiPo rechargeable battery - pricey, require proper isolation, can pillow => fails with toxic smoke and fires. And still this doesn't guarantee the data would be consistent. BTW, there was a thing back in the day, UPS which could be installed in the case (usually 2x5.25"). While it sounds neat, it's the worst of all other variants: small capacity - no place for a big battery needs servicing - every 3 years replacement for battery still can fail with sparks and fire

Libcat99 3y ago
This battery per device just means more devices would be broken, too. Just like the numerous ups and raid batteries I've had that reported they were fine until the moment they were actually needed.

vbezhenar 3y ago

ATX PSU must supply power for 16 ms after power off. It also supplies power good signal which can indicate that power is not available. So operating system has a chance to flush caches. Of course that's not few seconds, but should be enough for practical uses. I don't know whether popular operating systems implement this behaviour. Some server disks might have a backup power source, but that's certainly not a consumer hardware.