[General Topics] bofh999:
Ever since Android announced trim support this topic seems to be ignored ever since.

It shouldnt have been.

At least on some devices manual fstrim (busybox) of any version dont work, at least not fully properly as it should.

Never did, and i highly doubt it does work with android kernel built in command thats supposed todo that on its own.

That would explain the usual performance gain after formating data poartition at least for a few days.

I testet this over the years on S2, Note3, NExus 5, nexus 9 and a few other phones.

latest tests are note 3 and nexus 9 on lineage 14.1 (droid 7.2) and oreo.

Here is the results

On Android (native app, or shell via busybox):

it says it trims, consecutive trims lead smaller sizes and at some point to "trim not required" - as it should be.

However a fter a few minutes data trims again hundreeds of megs, an hour later gigabytes

- wtf - monitoring the write activity showed nothing at all. also the battery should be drained if it writes 20gigs an hour to the sdcard constantly - something seems off.

This behaviour has been as is ever since. fstrim never seem todo much.

Now we test this under twrp on the shell.

after one trim it was imidiatly to zero (so second trim says not required)

allright fine, this is how its supposed to be...

well .... nope ... after remounting it imiditaly wants to trim 100% of the free space.

ext4 is not supposed to work like this on trim, it should always only allow untrimmed freespace (in contrast to btrfs which always trims all).

Now important to know is that fstrim is no relyable method to find out if trim is working or what your block devices does.

it could be very well trim is working as intended but reports wrongly.

However the behaviour of trimming down to little, then to zero, then growing big and fast seems to indicate otherwise.

it looks more l ike trim job marks as trimmed (while its sheduled todo that really) - and unamrk step by step later

if this is true it also means the discard mount option actually is contraproductive at best.

Resolution:

i found that switching to f2fs solves that issue.

Trims are now realistic (like 300mb after 5 hours) zero for a long time, correct sizes when you delete a bigger file and so on.

also its now incredible fast.

the massive difference on my devices between f2fs and ext4 is another indicator that trim never worked. it seems like on the first day.

f2fs is supposed to be 20% slower on reads yet i have across all devices a massive improvment, no mroe lags or stutter on ceertain operations. specially chromiun based browser became lightning fast, as in only fractions of a second loading time, compared to seconds before (which make sense considering how the cache is working all the littel files take up an insane time if you need to clear those bytes first)

oh and did i mention it works very well with encryption on?

well it does, and thers no real speed difference now beween unecrypted and encrypted.

bottom line, i doubt trim ever worked on ext4 systems, at least not on all of them.

f2fs is teh solution at least for such older devices like mine, together with oreo my old ones are back in business... watining for a samsung note with on screen fingerprint reader and no knox :))