I think we’re talking past each other here: You are talking about blocks as physical delineations in an ssd, containing many pages with erase cycles. Op is talking about the filesystem view of blocks, which is different altogether. ZFS, for instance, should have its block size aligned with what a disk presents to the HAL, or you end up with lots of wasted space or terrible performance.

For SSDs (you’re right, outside op’s problem), the internal block size is usually much bigger than the emulated block size, often 128K. But we don’t use filesystems with 128K block sizes, or we couldn’t reasonable run databases or store small files.

There was a brief time in the wild west of SSDs being new where some shipped with 8k blocks, but this caused a bunch of problems for storage drivers because no one had yet decided if the translation of FS blocks to should be handled by filesystems or by disk firmware. We now let manufacturers decide how they should r/w to media, and trust the firmware’s presented block size.

That block size is now 4k for most disks, spinning or ssd. We still see some weird layouts in high-performance or high-endurance disks, but they are exceptions.

so if a 512e SSD doesn’t receive the rest of the page in time (e.g. with IO scheduling, 512 byte fs sectors, unaligned partitions, or bad luck)

I’m not sure what this means, pages are a concept in an ssd’s physical structure, they don’t mean anything to a filesystem (except in volatile memory).