[Galaxy Note GT-N7000 General] Tungstwenty:
Some more info on this erase / secure_erase stuff, from looking at the ICS vs JB kernel sources coming from the 9300.

Aside from the quirk flags activation for the Samsung faulty eMMCs, the main difference is in drivers/mmc/card/block.c:

static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
{
...
if (req && req->cmd_flags & REQ_DISCARD) {
/* complete ongoing async transfer before issuing discard */
if (card->host->areq)
mmc_blk_issue_rw_rq(mq, NULL);
if (req->cmd_flags & REQ_SECURE &&
[COLOR="Green"][B] !(card->quirks & MMC_QUIRK_MOVINAND_SECURE))[/B][/COLOR]
ret = mmc_blk_issue_secdiscard_rq(mq, req);
else
ret = mmc_blk_issue_discard_rq(mq, req);

The line in green has been added, which means that SECURE discard requests will fall back to regular discards if the chip is one of the faulty ones.

Both of the functions "mmc_blk_issue_secdiscard_rq" and "mmc_blk_issue_discard_rq" will ultimately issue the MMC_ERASE... command (in the function mmc_erase), although with different arguments:

- MMC_SECURE_TRIMx_ARG or MMC_SECURE_ERASE_ARG for the secure discard

- MMC_DISCARD_ARG, MMC_TRIM_ARG or MMC_ERASE_ARG for the regular one

Judging by the 9300 source changes, the only dangerous operation that Samsung is blocking for that set of chips is the secure one. They are assuming that the regular discard is safe.

Entropy512 has previously shared his opinion about the several wipe methods:

The "traditional" safety measure has been to disable MMC_CAP_ERASE altogether, but that blocks both the secure and non-secure erase (mmc_blk_issue_secdiscard_rq and mmc_blk_issue_discard_rq), which will return -EOPNOTSUPP.

This might cause some issues if the userspace binaries now start assuming that the erase request will not fail.

I'm using older builds and have stuff like this on my /data/log/recovery_log.txt:

[Formatting cache]
Creating filesystem with parameters:
Size: 104857600
Block size: 4096
Blocks per group: 32768
Inodes per group: 6400
Inode size: 256
Journal blocks: 1024
Label:
Blocks: 25600
Block groups: 1
Reserved block group size: 7
Created filesystem with 11/6400 inodes and 1438/25600 blocks
[COLOR="Red"][B]warning: wipe_block_device: Discard failed[/B][/COLOR]

However, the wipe operations do work because the recovery is likely ignoring that failure, since it has successfully created the filesystem structure. It "merely" didn't delete (or mark as deleted) the contents of the partition.

In JB roms there are however unintended effects of disabling MMC_CAP_ERASE, as Phil3759 mentions in this post. Formatting the internal SD from Settings / Storage / Format USB no longer works, which I assume is because the executed code errors instead of warning on that -EOPNOTSUPP kernel erase result.

The question now is ...

What to do?

I see 2 options:

- either continue to disable MMC_CAP_ERASE (on custom kernels or patching stock code)

- trust that indeed it's only the secure erase that causes the bricks and run the new JB kernels directly even for wipes

I don't have enough knowledge to suggest anything, I trust Entropy and some other folks that have shared very interesting stuff on this thread might have an opinion with the latest clues from Samsung.

From a

performance and durability

point of view, I now understand that blocking TRIM / DISCARD / ERASE - especially the non-safe - does cause impacts. Those who have the patience to read the Wikipedia page on TRIM will understand why.

But in a nutshell, a TRIM operation is an instruction for the controller to mark the pages as no longer used, which will:

- avoid a read being required before writing additional data on the same block (typically 512kb); that's "write amplification" and will make write operations slower due to the need of reading the block prior to erasing and writing it again

- ignore these blocks when garbage collection occurs (you can imagine it as something like a Windows drive defrag), making the operation faster and at the same time increasing the life of the card

As for the fact that the mount options don't include the "discard" flag, I imagine it's due to the performance impact. Since TRIM is a non-queued command (i.e. it's synchronous), calling it every time something is deleted would impact performance considerably. Instead, one could use "fstrim" whenever he wants to inform the eMMC which blocks are not used by the logical filesystem and can therefore be ignored when writing over them or when performing housekeeping.

Anyway, doing it on a kernel with MMC_CAP_ERASE disabled won't do anything.

"Absolute safety" or "assumed safety + efficiency" :confused:

PS: I wasn't able to follow the mmc_blk_issue_rq invocations back to the point where userspace binaries trigger that. If someone can point me to the path it would be interesting to see where that secure vs. non-secure discard decision along the way is done.