6 ms·

Not really a problem when your computer has a large UPS built into it. Desktop macs, not so good. But really isn’t the point of a journaling file system to mak

• monocasa 5y ago
  Journaling file systems depend on commands like FLUSH to create the appropriate barriers to build their journal's semantics.
  • rowanG077 5y ago
    I don't have a clue how a journaling FS works. But any ordering should not be observable unless you have a power outage. Can you give an example how a journaling FS could observe something that should be observable?
    • b112 5y ago
      A crash, lockup, are the same as a power failure.
      • colanderman 5y ago
        No, during a crash or lockup, acknowledged writes are not lost. (Because the drive has acknowledged them, they are in the drive's internal queue and thus need no further action from the OS to be committed to durable storage.) Only power loss/power cycle causes this.
        • throwaway2048 5y ago
          Drive firmware can crash or lockup too...
      • rowanG077 5y ago
        Why? During a crash or lockup acked writes still reached the drive. They will be flushed to the storage eventually by the SSD controller. As long as you have power that is.
        • joosters 5y ago
          The key word is ‘eventually’. How long? Seconds, or even minutes? If your machine locks up, you turn it off and on again. If the drive didn’t bother to flush its internal caches by then, that data is lost, just as in a power failure.
          • monocasa 5y ago
            100s of milliseconds is the right order of magnitude.
            • jlokier 5y ago
              I think at least 1-2 seconds. I measured the performance of different size direct I/Os on some Samsung SSDs, and the write performance when switching from one test to another was significantly affected by the previous test parameters, or not, depending on whether a "sleep 2" was inserted between each test. The only explanation I can think of is that the flash reorganises or commits cached data during that 2 seconds.
              • wtallis 5y ago
                If you were using consumer SSDs, you have multiple layers of caching to worry about: in the controller's SRAM, and in a portion of the flash that's operating as SLC. There are also power saving modes to consider; waiting long enough for the drive to drop to a sleep state means you'll incur a wakeup penalty on the next IO.
            • marcan_42 5y ago
              It's at least 5 seconds on Apple SSDs. Not sure if they even lazily flush at all. They might rely on the OS to periodically issue flushes (I heard launchd does that every 30 seconds).
      • marcan_42 5y ago
        macOS flushes the NVMe cache on kernel panic. Probably not on lockups though. A watchdog reset won't flush NVMe. Not sure if they have a special pre-fire path that tries a last ditch NVMe flush...
    • monocasa 5y ago
      > unless you have a power outage Journaling FSes are all about safety in the face of such things. That is, unless the drive lies.
    • nwallin 5y ago
      > But any ordering should not be observable unless you have a power outage. But what if the front does fall off?
    • mnw21cam 5y ago
      The simplest answer is that the journal size isn't infinite, and not everything goes into the journal (like often actual file data). Therefore, stuff must be removed from the journal at some point. The filesystem only removes stuff from the journal once it has a clear message from the drive that the data that has been written elsewhere is safe and secure. If the drive lies about that, then the filesystem may overwrite part of the journal that it thinks is no longer needed, and the drive may write that journal-overwrite before it writes the long-term representation. That's how you get filesystem corruption.
  • jnwatson 5y ago
    From the filesystem's perspective looking at storage, the flush does indeed preserve the semantics. It is just that you can't rely on the contents of anything if the power goes out.
  • deleted 5y ago
    [deleted]
• withinboredom 5y ago
  > Not really a problem when your computer has a large UPS built into it. Except that _one time_ you need to work until the battery fails to power the device, at 8%, because the battery's capacity is only 80%. Granted, this is only after a few years of regular use...
  • monocasa 5y ago
    In Apple's defense, they probably have enough power even in the worst case to limp along enough to flush in laptop form factor, even if the power management components refuse to power the main CCXs. Speccing out enough caps in the desktop case would be very Apple as well.
    • marcan_42 5y ago
      Apple do not have PLP on their desktop machines (at least not the Mac Mini). I've tested over 5 seconds of written but not FLUSHed data loss, and confirmed via hypervisor tracing that macOS doesn't do anything when you yank power. It just dies.
      • monocasa 5y ago
        With truly no PLP I'd expect unrecovarable drives that have screwed up their FTL when you pull power.
        • marcan_42 5y ago
          You can design your FTL to be resilient to arbitrary power loss, as long as the NAND chips don't physically go off corrupting unrelated data on power down. That only requires extremely minimal capacitance. I believe Apple SSDs do have some of that in the NAND PMIC next to the storage chips themselves; it probably knows to detect falling voltage rails and trigger a stop of all writes to avoid any actual corruption due to out-of-spec voltages.
          • monocasa 5y ago
• joenathanone 5y ago
  UPS won't help if kernel panics.
  • colanderman 5y ago
    It doesn't need to, kernel panic alone does not cause acknowledged data not to be written to the drive. UPS is not perfect though, it's better if your data integrity guarantees are valid independent of power supply. All that requires is that the drive doesn't lie.
  • metalliqaz 5y ago
    kernel panic wouldn't take out the SSD firmware...
    • dathinab 5y ago
      To quote Apples man pages: > Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written.
      • colanderman 5y ago
        mac OS's fsync(2) doesn't wait for SCSI-level flush, unless F_FULLFSYNC is provided.
  • marcan_42 5y ago
    macOS issues an NVMe flush on kernel panics.
• colanderman 5y ago
  Hard drive write caches are supposed to be battery-backed (i.e., internal to the drive) for exactly this reason. (Apparently the drives tested are not.) Data integrity should not be dependent on power supply (UPS or not) in any way; it's unnecessary coupling of failure domains (two different domains nonetheless -- availability vs. integrity).
  • nomel 5y ago
    > it's unnecessary coupling I think much improved write performance is a good example of how it can be beneficial, with minimal risk. Everything can be nice ideals of abstraction, until you want to push the envelope.
    • colanderman 5y ago
      Accidental drive pulls happen -- think JBODs and RAID. Ideally, if an operator pulls the wrong drive, and then shoves it back in in a short amount of time, you want to be able to recover from that without a full RAID rebuild. You can't do that correctly if the RAID's bookkeeping structures (e.g. write-intent bitmap) are not consistent with the rest of the data on the drive. (To be fair, in practice, an error arising in this case would likely be caught by RAID parity.) Not saying UPS-based integrity solutions don't make sense, you are right it's a tradeoff. The issue to me is more device vendors misstating their devices' capabilities.
  • oceanplexian 5y ago
    As a systems engineer, I think we should be careful throwing words around like “should”. Maybe the data integrity isn’t something that’s guaranteed by a single piece of hardware but instead a cluster or a larger eventually consistent system? There will always be trade-offs to any implementation. If you’re just using your M2 SSD to store games downloaded off Steam I doubt it really matters how well they flush data. However if your financial startup is using then without an understanding of the risks and how to mitigate them, then you may have a bad time.
    • colanderman 5y ago
• dathinab 5y ago
  > Not really a problem when your computer has a large UPS built into it. Actually it is (through a small one) to name some examples where it can still lose without full sync: - OS crashes - random hard reset, e.g. due to bit flips due to e.g. cosmic radiation (happens). Or someone putting their magnetic earphone cases or similar on your laptop or similar. Also any application which care about data integrity will do full syncs and in turn will get hit by a huge perf. penalty. I have no idea why people are so adamant to defend Apple in this case, it's pretty clear that they messed up as performance with full flush is just WAY to low and this affects anything which uses full flushes, which any application should at least do on (auto-)safe. The point of a journalism file system is about making it less likely the file system _itself_ isn't corrupted. Not that the files are not corrupted if they don't use full sync!
  • colanderman 5y ago
    OS crashes do not cause acknowledged writes to be lost. They are already in the drive's queue.
    • dathinab 5y ago
      They do if you don't use F_FULLSYNC, even apple acknowledges it (quote apple man pages): > Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written. It's also worse then just write losses: > The disk drive may also re-order the data so that later writes may be present, while earlier writes are not.
      • colanderman 5y ago
        I'm using "acknowledged" in the sense of SCSI-level flush (per the thread OP), not mac OS's peculiar implementation of fsync.
        • dathinab 5y ago
          But the thread OS is about it not being a problem that SCSI-level flushes are supper slow, which is only not a problem if you don't do them (e.g. only use fsync on Mac)? But reading it again there might have been some confusion about what was meant.
• emodendroket 5y ago
  It seems pretty clear that desktop Macs are an afterthought for Apple.
• lmilcin 5y ago
  Power loss is not the only way things can stop working.