[Samsung Epic 4G Touch] Lanchon:
thank you!! andrew, the brickbug hero!!! :)

yeah ive seen that, and my chip pre-dates that one. these samsung parts are cans of worms. i got myself an intel SSD, i didnt want those engineers near my data :)

now this is a friend's phone. he has wiped it many times (on stock 4.1.2) , no bricking. he wipes it because after a couple of months the phone goes dead slow. i wanna bring new life into it. but if i set it up with CM, which i understand blocks all erases (they still do?), after that then not even wiping is going to help. fstrim might also not work on CM kernel. (i dont really know, its very hard to know the current state of the kernel by googling after so much discussion went on on the web.)

now i know that you are suspicious of samsung's fix, that you dont trust non-secure erases even though samsung has stated they are safe. but samsung has the emmc code, fixed the bug on later firmwares, and thus supposedly understood it. so my question to you is: is there any evidence pointing in the direction of non-secure erases being dangerous? or is it just speculation? i suppose thousands of people have wiped on stock 4.1.2. do we know of bricks?

pardon my insistence on this, but if you picture the implementation of an ssd translation layer in your head, i think samsung's fix sounds all too believable.

so the algorithm deals with sectors and erase blocks, and at a minimum would maintain these data structures:

-list of erased blocks

-list of reserved erased blocks

-list of used blocks

-list or maybe just one partially used, partially erased block (would depend on the parallelism of the nand bank for instance)

used and partially used blocks contain sectors, each made of data, ecc and metadata.

in a possible implementation, sector metadata contains at least:

-sector number (a.k.a. address)

-used flag

-deleted flag

finally it needs an map (maybe only in ram, constructed by scanning all metadata on emmc boot) of sector number to current nand address (if any, as sectors may be empty; ie: erased).

so reading from the emmc is trivial, and writing is conceptually simple:

1) pick an empty sector (in the current partially used block, or start using an new erased block)

2) write data, ecc and sector number to the new sector

3) mark the new sector as used

(note: this flag and its delayed write prevents partial sector number writes (say, during powerdown) from being considered valid on the next powerup scan, and thus prevents corruption of data in random sector numbers that were not being written during powerdown.)

(note: if powerdown happens here, scanning on next powerup can conceptually map any of the two copies and delete the other one. actually, it should move whatever chosen sector's data to a new sector and delete both, because the deleted flag might read false now, but actually be partially programmed, so it could read true any time later. and you dont know which of the two deleted flags could be compromised. and you cant clear the flags, you can only erase blocks.)

4) if map shows this sector number contains data, mark the old sector metadata as deleted.

5) set or update this sector number's map entry to point to the new sector nand address

and of course, the tricky part is 1). if no empty sectors remain, its time to garbage collect: find blocks with mostly deleted sectors, consolidate their non-deleted sectors into reserved erased blocks, erase the freed blocks, restock the reserved list, put the rest on the empty list. (all this done transactionally, because power can be lost any time, and nand areas can fail.) finally retry 1).

now lets accept all this works: no emmc bricks by just writing on it. hypothesis: samsung got this right.

so what is an non-secure erase then? trivial:

-if map shows this sector number contains data:

--mark the old sector metadata as deleted.

--clear this sector number's map entry

non-secure erase is THE simplest *update* operation the translation layer can do. if samsung got writes right, could they have got this trivial operation wrong?

finally, how does one do secure erase? this is much more complex. you start with the erase range. the map is useless as previous stale (deleted) data within the range is not pointed by it. so you scan the complete nand. for each (partially) used block, if the block has any sector whose metadata shows it belongs to the range, even if deleted, then the block must be erased. (also erase the block if any sector is a partial write (ie: powerdown while write), as its partial data could potentially have belonged to the range.) to do this, the non-deleted sectors of the block must be transactionally relocated and consolidated. this IS much more complex, and also not tested (thanks samsung!) and thus... bugs!

a very naive implementation would be:

-for each used or partially used block:

--if any sector of the block is partially written or matches the erase range:

---for each used, non-deleted, non-range-matching sector of the block:

----read it

----write it (as per the standard write above)

----if last write triggered a garbage collection:

-----abort and start scanning the nand from the beginning again

----if last write wrote in the currently scanned partially used block (well, at least previously partially used):

-----abort inner loop and start relocating used, non-deleted, non-range-matching sectors of the current block again

---erase current block NOW (dont deffer!)

-for each sector number in range:

--clear its map entry

a non-restarting algorithm would be more complex, as the garbage collector has to closely coordinate with the nand scanner. or otherwise the scanner has to implement its own special GC.

and yes, of course: this lazy housekeeping is not the real way to do stuff. GC and other maintenance chores are done eagerly during idle periods, and should be abortable or pausable to reduce latency when a host request arrives.

and also: used and deleted flags are prone to be half-programmed (powerdowns) thus causing data loss or rollback that can happen an arbitrarily long time after the powerdown and this is unacceptable. duplicated flags, written in sequence (or maybe at the same time if physically designed to have different programming times) can protect from this issue. (which in turn requires a flag to signal that a given sector number will be unreadable when next read.) and the flags themselves could fail nand-wise, so they have to have even more redundancy for handling that. and sector number too: maybe add parity then store it twice, or some other ecc. and then comes the whole issue of nand defect management... etc etc :)

--------------

but anyway, all this was to prove that samsungs fix does sound sensible. a hole in theory is the expected lack of testing of non-secure deletes. but the operation is so trivial, and a strict and very small subset of the write operation, that it would sound believable that they got it right even on the first try.

so with this in mind, is there any evidence pointing at non-secure erases bricking?

and if not, given that the lack of trim makes the devices completely unusable over time, shouldnt the CM team consider switching to a samsung-style fix instead of blocking all erases?

oh, and very sorry for the long post, i didnt know how else to argue my point :) thanks!!!