4 ms·
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 journalin
by 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 agoA crash, lockup, are the same as a power failure.
- colanderman 5y agoNo, 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 agoDrive firmware can crash or lockup too...
- rowanG077 5y agoWhy? 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 agoThe 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 ago100s of milliseconds is the right order of magnitude.
- jlokier 5y agoI 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 agoIf 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 agoIt'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).
- colanderman 5y ago> you turn it off and on again That would be a power failure. Kernel crash is not equivalent to that. System reboot doesn't entail power failure either. The disks may be powered by an independent external enclosure (e.g. JBOD). All they see is that they stopped receiving commands for a short while.
- marcan_42 5y agoIt's at least seconds. Apple's NVMe controller does not try to eagerly flush unflushed writes. That said, macOS does issue a flush on kernel panic, and I'm hoping to be able to do the same on Linux.
- marcan_42 5y agomacOS 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 agoThe 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.