Originally Posted by samarium
bauner produced a new n7000 IsoRec with TWRP + OTG which I wanted, so while I was installing I tested a few things.
I generated a block binary file with each of the 1kB blocks annotated for the 200MB n7000 cache partition, and dd'd the file to the cache partition prior to each mkfs.
$ cat blocknull.pl
my $count = $ARGV;
$count = 1 if $count == 0;
$count *= 1024 if $ARGV =~ /M$/;
$count *= 1024 * 1024 if $ARGV =~ /G$/;
for (my $i = 1; $i <= $count; $i++)
printf "\nBLOCK %10d kB %6d MB %2d GB BLOCK\n", $i, $i / 1024, $i / 1024 / 1024;
print chr(0) x (1024-43);
BLOCK 1 kB 0 MB 0 GB BLOCK
BLOCK 204800 kB 200 MB 0 GB BLOCK
Then operated on both vfat and ext4 file systems to determine which of the 204800 block signatures where remaining after various operations.
# tr -d '\0' < /dev/block/mmcblk0p7 | grep BLOCK.*BLOCK > cache.x.y.desc
# wc -l cache.?.?.*
So as expected vfat format doesn't change the underlying data returned, it just gets changed as it is used, as show by the signature counts on cache.1.*
ext4 is more interesting, as I tried a manual mke2fs -t ext4 for cache.2.* and TWRP wipe ext4 for cache.3.*. The TWRP wipe is not using secure discard as can be seen from recovery.log, but things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.
warning: wipe_block_device: Wipe via secure discard suppressed due to bug in EMMC firmware
Maybe more interesting is that even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed, which I don't expect, some inconsistency in fs metadata setup in mkfs maybe? Doesn't matter to me, 1 or 2 wipes, but seems I will be using mke2fs -t ext4 via terminal and then using TWRP wipe/format as required.
FYI, EMMC IDs PNG attached.
>it seems manual mke2fs -t ext4 does a wipe
it shouldn't. mke2fs -i thought- doesn't trim unless invoked with a specific option. repit invokes with the flag:
as to the question of why your markers were cleared anyway, i've no answer.
>even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed
some kernels inform the newly trimmed space: if you run trim twice you'll get "0 bytes trimmed" the second time.
other kernels (like CM's i9100) always inform (and presumably trim) the full partition free space, so 180MB is ok. if you run trim twice you'll get the same number of bytes both times.
>things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.
here are some candidate causes:
a) ext4 fs is based on 'blocks' with each block being a constant number of sectors. it makes sense that fstrim should work on whole blocks. also, when ext4 writes a 'short block', ie one not completely filled with data, some sectors and the end of the block might remain unused. it makes sense for ext4 not to write these sectors at all. but the complete block will be marked as used given that the block is the granularity for that, so no sector in the block will be trimmed by fstrim. so some pre-format data might survive in these short blocks after fstrim by this mechanism, which could explain what you observed.
b) another cause could be that the emmc might ignore trim requests for spans shorter than some size or for misaligned spans (remember that erases are performed in large chunks) giving rise to the observed data survival. when formatting no data survives because partitions are position- and size-aligned to 1MB or 4MB, which might be enough to guarantee trim. (i find this explanation unlikely, but who knows.)
repit formats and trims ext4 and f2fs in a single operation.
to wipe /data a single repit should be enough:
to wipe /sdcard you can take advantage of repit's capability to convert file systems and do two repits:
an idea that comes out of this is that repit could temporarily format in ext4 before formatting in other modes that do not support format-time trimming, such as when wiping vfat and swap. this would make the above 2 steps unnecessary.