[Samsung Galaxy Nexus] a3361035:
Overprovision area is 5% not 15.5%. That discrepancy looks too big, so only a partial explanation.

Seems like f2fs filesystem structure has it's own fixed overhead for small sizes. Different overprovision settings might help. Core f2fs dev recommends 20% for a 128M partition to get more free space, but still loses like 45%:

http://article.gmane.org/gmane.linux.file-systems.f2fs/905

Also f2fs does report space different than ext4.

http://article.gmane.org/gmane.linux.file-systems.f2fs/123

(Also shows that f2fs filestructure doesn't use more space than ext4 for bigger partition sizes anymore)

So for us:

df -h
Filesystem Size Used Available Use% Mounted on

ext4:
/dev/block/mmcblk0p10
643.7M 11.0M 632.7M 2% /system

mkfs.f2fs:
/dev/block/mmcblk0p10
652.0M 122.0M 516.0M 19% /system

mkfs.f2fs -o 8:
/dev/block/mmcblk0p10
652.0M 108.0M 530.0M 17% /system

8% overprovision seems best (tested like 1-10,15,20) but it's still 102.7MB less than ext4 and only 14MB better than default 5%.

[MENTION=4608636]bsmitty83[/MENTION]:

Why's f2fs-tools so old in TWRP-2.7.1.1-f2fs-MAGURO: mkfs.f2fs Ver: 1.1.0 (2012-11-29)?

Afaiu different versions will produce different superblocks/filesystems and there's no guarantee for backwards-compatibility:

http://git.kernel.org/cgit/linux/ke...N?id=dd1ba078fae270c4174a221a873026fea85aae32

So prolly not a good idea to use old f2fs-tools but track latest f2fs commits in the kernel.

P.S. That zip is signed wrong.

Looking at those mount options. Why isn't inline_data set? To quote lkml:

https://lkml.org/lkml/2013/11/10/48

There's no trim on delete. That's a mischaracterization of f2fs' discard mount option. It trims on cleaning. But even the cost-benefit background cleaner seems to run every 30-60 secs.[0]

Where do you want fsck support?

You don't want a half-broken fstrim. It should run or not run because we want to, not because it's broken. For example Ubuntu 14.04 fstrim-all doesn't run, when it detects the discard mount option. [1]

Cleaner runs on the filesystem, trim on the actual device [2]

Cleaner is triggered by the kernel.

[0] http://article.gmane.org/gmane.linux.file-systems.f2fs/373

[1] https://plus.google.com/107564545827215425270/posts/D2SB1zxb9Z9

[2] http://en.wikipedia.org/wiki/TRIM

===

Do the section/zone size from Galaxy Nexus's eMMC align with the ones from f2fs?

Do all eMMC' versions in the Galaxy Nexus have the same?

>cat /sys/block/mmcblk0/device/name
VYL00M
>cat /sys/block/mmcblk0/device/preferred_erase_size
524288

Assuming that erase size is true (might not be, should be confirmed with flashbench[0]), f2fs defaults do not align with the FTL.

mkfs.f2fs -s only accepts integer values, so out of luck.

How about some reliable tests?

Did someone port fsstress/dbench/other suitable tools to android yet?

How about some robustness tests?

For example randomly pull the battery and run fsck afterwards.

Entropy512 said robustness is horrible: [1]

To which some Motorola dev responded and said they improved that in their f2fs implementation. [2]

[MENTION=4608636]bsmitty83[/MENTION]:

Why are you using upstream f2fs and not Motorola's?

https://github.com/MotorolaMobilityLLC

[0] https://gitorious.org/flashbench

[1] http://xdaforums.com/showpost.php?p=50098995

[2] http://xdaforums.com/showpost.php?p=51565669