See man pages for mkfs.xfs, mkfs.ext4. On other Unix systems block size is/was more variable, but on Linux you can't exceed the 4kB memory page size. So it is not possible to match database block size (typically 16kB for InnoDB, 8kB for PostgreSQL). (Exception being ZFS which has a completely different architecture and can do atomic writes.) Note that I am not saying buffered IO would necessarily be atomic at that level on (say) ancestral SGI XFS or FreeBSD UFS with block size matching the database's (I don't know if it might it some circumstances split writes on sector boundaries for some reason)! Just that it's already a non starter when the block size is too small.

Thank you for the clue. All the reviews I had read claimed Intel and Samsung SSEs were bulletproof, and everybody else's were trash.

For $300, it should have been a better product. Only 6 months later the competition was getting only $100 for them.

Sad. I have a 9yr old Intel ssd that still benchmarks like new.

> This won’t fit on certain consumer motherboard.

From diving into this recently in speccing out a budget system for myself, it looks to be mostly the lower end budget chipsets and motherboards that don't support it. At least that's what I've seen of the regular sized ATX boards, but it may be a different story for Micro-ATX or Mini-ITX.

The relevant info is always in the specs, and will look something like:

  M.2 Slots
    2242/2260/2280/22110 M-key
    2242/2260/2280 M-key

For each of those, the first two numbers are the width, the rest denote the length. So 2280 is 22mm x 80mm, and 22110 is 22mm x 110mm.

Intel's "Intel® Optane™ Memory H10 with Solid State Storage" is an Optane/QLC flash hybrid drive with an NVMe interface and capacities up to 1TB. It claims to offer enhanced power loss data protection:

https://www.intel.com/content/www/us/en/products/memory-stor...

I found this review which makes it sound pretty reasonable:

https://www.tomshardware.com/reviews/intel-h10-qlc-flash-opt...

Consumer Crucial/Micron drives used to have enough capacitors on board to, at least in my understanding, never corrupt data on power loss (not sure if they flushed the cache, but I think they at least tried and guaranteed sectors wouldn't become unreadable/corrupted due to being partially written). They dropped this in later models, though, but I think they still claim they can guarantee non corruption/partial writes?

I stopped trusting Crucial when they released the P1 though. That QLC drive is terrible on every metric. Performance falls off a steep cliff once you do any writes at all, and often never quite recovers. Tail latencies are in the 1 second range, which is insane for an SSD.

SLC cache looks like another consumer feature that not supported on enterprise drives maybe due to inconsistent performance.

Rather interestingly, despite obviously having a bank of large capacitors and conspicuous advertising of power loss protection, the firmware on that drive identifies it to the host system as having a volatile write cache.

Last weekend my ThinkPad running ZFS on Linux on a Samsung non-power-loss-protected consumer SSD lost various files when it ran out of power (including the entire Thunderbird profile because its SQLite DB was corrupted).

I'm planning to replace it by the SSD linked above.

I was already aware of the power loss issue on consumer SSDs (from the 2013 piece http://lkcl.net/reports/ssd_analysis.html), but I wanted to see it happen for real. I guess I did now.

UPSs are never really cheap, since when converting AC to DC to AC you lose a significant amount of power efficiency for your equipment. The funny part is the server PSU then converts back to DC power yet again. My understanding is that well optimized data centers distribute conditioned, battery backed DC power directly to devices to avoid those double conversion losses.

> Is there a standard for PSU's about how long they provide power, that SSDs could design to?

Yes. The ATX power supply spec has timing requirements for the PWR_OK signal. As described on Wikipedia:

> The ATX specification requires that the power-good signal ("PWR_OK") [...] remain high for 16 ms after loss of AC power, and fall (to less than 0.4 V) at least 1 ms before the power rails fall out of specification (to 95% of their nominal value).

So power supplies are expected to continue operating through roughly a single missing cycle of AC power, but they only have to give the system 1ms of warning when power is going out. This signal would have to be delivered to the SSD by software in the form of a shutdown notification (a write to a particular NVMe register).

And now that I think about it, that shutdown notification mechanism probably warrants inclusion in the article.

That wasn't the same thing. Crucial SSDs always had volatile write caches. What their MX series and at least some of the NVMe drives offer is the guarantee that data already on the flash will not be corrupted by a write that's in progress when the power fails. But that doesn't affect the semantics of writes that may still be pending in the volatile write cache.

This potential failure mode is possible when storing more than one bit per flash memory cell, and using a multi-step process to program the cell voltage, and mapping the low-order bits of a cell's value to different LBAs than the high order bit. Drives need to have the capability to either complete or safely abort an in-progress cell program process so that the value in the high-order bit(s) isn't corrupted by an incomplete programming of the low-order bit(s). And this power failure problem isn't the only reason why SSDs need to be careful about leaving cells in a partially-programmed state.

Wow, this jogged a memory from when Brad Fitzpatrick (bradfitz on HN) had to write a utility to ensure the hard drives running LiveJournal didn't lie about successfully completing fsync().[1] IIRC, the behavior caused fairly serious database corruption after a power outage.

Went back and found the link. To my surprise, it was 15 years ago. To my greater surprise, the original post, the Slashdot article, and the utility all remain available.

And hard drives (or their NVMe successors) still lie.

[1] https://brad.livejournal.com/2116715.html

> This is surprisingly common behavior.

Anecdotally, consumer NVMe SSDs actually tend to not lie about it. Every time I've benchmarked a consumer NVMe SSD under Windows both with and without the "Write Cache Buffer Flushing" option, it has a profound impact on the measured performance of the SSD. I have not observed a comparable performance impact for SATA SSDs, so I suspect Microsoft's description of what that option does is inaccurate for at least one type of drive, though it is at least possible that ignoring flushes is extremely common for consumer SATA SSDs but uncommon for consumer NVMe SSDs.

But as long as you write the journal entry first and the device guarantees flushes for writes in the order they are queued, there should be no inconsistent state at all?

It's worthy of note that log-structured and copy-on-write filesystems (which I've seen described as two types of journaling) like btrfs and F2FS log data as part of their normal operation without any performance loss, so you always get a consistent view of the filesystem (barring bugs in the FS code or fsync-is-not-really-an-fsync treachery from your hardware).

As long as writes are flushed sequentially, I see no problem with metadata only journaling, but apparently, NVMe's don't provide such guarantees.