Am Mon, Apr 17, 2023 at 10:45:46AM -0700 schrieb Mark Knecht: > And I don't know that formatting ext4 or some other FS to 16K > really helps the write amplification issue but it makes sense to > me to match the file system blocks to the underlying flash > block size.
The problem is finding out the write block size. This 7-year-old post says it’s reached 16 K: https://superuser.com/questions/976257/page-sizes-ssd So I would say don’t bother. If everything is trimmed, there is no amplification. And if the disk becomes full and you get WA when writing itsy-bitsy 4 K files, you probably still won’t notice much difference, as random 4 K writes are slow anyways and how often do you write thousands of 4 K files outside of portage? Erase block sizes probably go into the megabytes these days: https://news.ycombinator.com/item?id=29165202 Some more detailed explanation: https://spdk.io/doc/ssd_internals.html “For each erase block, each bit may be written to (i.e. have its bit flipped from 0 to 1) with bit-granularity once. In order to write to the erase block a second time, the entire block must be erased (i.e. all bits in the block are flipped back to 0).” This sounds like my initial statement was partially wrong – trimming does cause writing zeroes, because that’s what an erase does. But it still prevents write amplification (and one extra erase cycle) because neighbouring blocks don’t need to be read and written back. > Real speed testing would be required to ensure reading > 16K blocks doesn't slow him down though. Here are some numbers and a conclusion gathered from a read test: https://superuser.com/questions/728858/how-to-determine-ssds-nand-erase-block-size Unless I positively need the speed for high-performance computing, I’d rather keep the smaller granularity for more capacity at low file sizes. A problem is what some call “parts lottery” these days: manufacturers promise some performance on the data sheet (“up to xxx”), but not with which parts they want to achieve this (types of flash chips, TLC/QLC, controller, DRAM and so on). Meaning during the lifetime of a product, its internals may change and as a consequence those specs are not in the data sheet: https://unix.stackexchange.com/questions/334804/is-there-a-way-to-find-out-ssd-page-size-on-linux-unix-what-is-physical-block “There is no standard way for a SSD to report its page size or erase block size. Few if any manufacturers report them in the datasheets. (Because they may change during the lifetime of a SKU, for example because of changing suppliers.) For practical use just align all your data structures (partitions, payload of LUKS containers, LVM logical volumes) to 1 or 2 MiB boundaries. It's an SSD after all--it is designed to cope with usual filesystems, such as NTFS (which uses 4 KiB allocation units).” -- Grüße | Greetings | Qapla’ Please do not share anything from, with or about me on any social network. The worst disease is indifference. So what?
signature.asc
Description: PGP signature
