F2FS experiences

[DrYak]

FYI Manjaro's installation images currently produce severely misaligned partitions

I'd fix this even if I wasn't going to change FS type.

It's not limited to Manjaro, I've seen images of Raspbian assuming some small alignement too...

Non 4kB aligned partitions are usually really bad.  {...}  But most likely it means each write to a 4kB ext4 (or other fs) block involves a read-modify-write cycle to the two flash blocks (of unknown size, 2k? 4k?) that the ext4 block overlaps.

This 4kiB doesn't matter any more nowadays.

That used to be important once HDD with 4kiB sectors (either natural 4KiB, or actually 4KiB but simulating a 512b to not disturb the OS), because exactly what you discribbed would happen.

That's not the case anymore with Flash (and also with shingled HDD), because most flash is organised in erase blocks: even if they can write sectors of 512b or 4KiB, they can only write those over free space, but they can't erase anything smaller than 2MiB ~ 8MiB (depending on FTL and on number of bits per SLC/MLC/TLC/etc. )

Trying to overwrite and change in-place any content small than that size will always trigger a read-modify-write cycle. (with the small details that the erase block that get "read" and "erased", and that the erase block that get actually "written with the modified version", might actually be two different block in order to rotate which blocks get erased and spread the wear).

That why log-structured filesystems (like F2FS) or copy-on-write filesystems (BTRFS, ZFS, BCacheFS) are better for flash:
They *never* modify/overwrite inplace (which will invariably trigger a read-modify-write). They *always exclusively* append writes by definition (which can be write-only by allocating fresh free erased blocks from the wear levelling pool).

What this means really depends on what the secret FTL inside the eMMC does.  Maybe the firmware in it is smart enough to detect "screwed up partition table" and it offsets all the LBAs by 1? 

I wouldn't put too much hope on such a small / cheap chip :-)

It would also be nice if they'd take those magic locations for the idbloader and so on and make them partitions. It's entirely possible to add them at the exact spot where the boot loader(s) will look for them. Then no more magic dd offsets need to be used, just go straight to the partition.

GPT partition tables allow exactly that with BIOS boot partitions (21686148-6449-6E6F-744E-656564454649).
I have formatted my NVMe this way.

And use a gpt table, so partition labels can be used.  Then idbloader.img goes to "/dev/disk/by-partlabel/idbloader".  No more keeping track of partition numbers.

Mine is called uboot.