As you guys may know our devices got a eMMC superbrick bug since 2012 which posted by CM TEAM
it also present a report and patch solution provide by Samsung was disable the secure erase completely
(VAL00M)MoviNAND
but it also cause one problem,Trim function broken
CM Report and workaround
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Trim documents:
https://en.wikipedia.org/wiki/Trim_(computing)
(This has been happen and report nearly 2 years ago,but no one concern or even intended to do somthing for bring back the trim)
Without Trim,it did not means our phone will have any data lost,
but you short feel your devices getting slower day by days,
Because the system cannot told to the SSD/eMMC controller the block has been cleared
also SSD/eMMC controller doesn't know the blocks has been cleared too
it just increase the searching time....
How does the SSD/eMMC sector design
the SSD/eMMC sector was using 4k as smallest store capacity(we called 1 paged),1 sector block=128Page So that mean
1 block sector size was 512KB,Even the SSD or eMMC or NAND minium writing/reading could smallest as 4KB
but when you need to do a wipe/erase operation,it need operate one block(512kb) each time
Write=4KB,Wipe=512KB eachtime
Let's use an example for more easier learning
When you need to written a new 3kb files to the ssd/nand flash,it will store as 4kb in the sector
However if the sector block has been present a data already,SSD/NAND/eMMC controller cannot just wipe that 4KB sector to write a new data
it need to move the new 512KB blocks data to the cache>wipe and erase the orignal 512KB blocks>Modified your writing files(4KB) in the cache and move it back to the sector
That means if more writing operation,the SSD and NAND/eMMC do more above action=>then it will decrease the performance
How does trim doing to solve it?
Trim work like a maid of your SSD/NAND/eMMC controller
when you deleted the files,it will just marked the block which need to wiped for writing operation and it will wait until the system idle for doing the above action silently
trim also work like a recycler and ,it could told the eMMC/SSD/NAND control to wipe and controlled each sector blocks more effective(no need to move any unrelated or random blocks for each new writing operation) and decrease the searching time for th
Why we cannot be trim?
As My mention at first paragraph due to the superbrick workaround
the erase function has been disable in the kernel(remember our eMMC support trim!)
to bring back the trim work it need to reenable the erase function
Trim require erase function work as well
even we have secure erase bug,it could still using non-secure erase for trim to work
Does it means there was no solution to brick back the trim
the answer is No,
Luckly some xda menber already know about this and try to workaround to bring back trim function work
which call Project BricksBUGS
http://forum.xda-developers.com/andr...ering-t2823051
I have already adding the fstrim to the kernel even to the Rom
Does it means it could doing?
No,As I mention the erase function didn't enable(No one intended to do also)
,so you cannot use trim function
not relation with your android version,
Someone said 4.3 or higher cannot run Lagfix and will got operation was not support at endpointed devices
that is incorrect,
Because Google just implement the automatic trim,which was calling fstrim to do such function started at 4.3 while the users was idle.
if the kernel has disabled the require feature,even it have any binaries,it doesn't mean trim can work no matter any android version you have.the function was provide by hardware requirement and Kernel,not the system itself
That means it require our SGR Kernel experts to concern and reenable about it
if we need trim you have to re-enable the erase
For workaround to bring back function
please follow the project brickbug.(it need to modified the)
http://forum.xda-developers.com/andr...ering-t2823051
But our devices was affected by brick bugs,It still safe to trim
Maybe. Folklore says no,For me,I will says you should know that any action which will touch the internal setting was your own risk it could cause your devices broke down,
Also If I need to choose for performance but will have risk to brick and stable but slower than unsual
I will choose the first one,because even you got the safe as brick risk,but slower can let the phone more unstable than brick risk
it will affected our daily usage than just a brick
but according my test result,trim can bring back it was safe
Let me do an experements without the samsung patch
I have tested with 4.0.4(Official ICS TGY-ZSLPD)(no any patch!,just rooted)
Without the patch you could run the trim correctly
When you are using the Lagfix or terminal with busybox which installed fstrim
It has been test more than a months already,I have been schedule fstrim each days,it still fast as when I buying this phone
Sometime I may doing trim more than one time at one days too
I"m not sure other SGR buddy would same as my result,(no data lost or brick)
but I would say,according my result I would support to bring back the trim for our devices as experiments
if you are worrying don't do any roots even trim
Important Documents for Kernel Developer
Project BricksBUGS by @Lanchon
http://forum.xda-developers.com/andr...ering-t2823051
it also present a report and patch solution provide by Samsung was disable the secure erase completely
(VAL00M)MoviNAND
but it also cause one problem,Trim function broken
CM Report and workaround
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Trim documents:
https://en.wikipedia.org/wiki/Trim_(computing)
(This has been happen and report nearly 2 years ago,but no one concern or even intended to do somthing for bring back the trim)
Without Trim,it did not means our phone will have any data lost,
but you short feel your devices getting slower day by days,
Because the system cannot told to the SSD/eMMC controller the block has been cleared
also SSD/eMMC controller doesn't know the blocks has been cleared too
it just increase the searching time....
How does the SSD/eMMC sector design
the SSD/eMMC sector was using 4k as smallest store capacity(we called 1 paged),1 sector block=128Page So that mean
1 block sector size was 512KB,Even the SSD or eMMC or NAND minium writing/reading could smallest as 4KB
but when you need to do a wipe/erase operation,it need operate one block(512kb) each time
Write=4KB,Wipe=512KB eachtime
Let's use an example for more easier learning
When you need to written a new 3kb files to the ssd/nand flash,it will store as 4kb in the sector
However if the sector block has been present a data already,SSD/NAND/eMMC controller cannot just wipe that 4KB sector to write a new data
it need to move the new 512KB blocks data to the cache>wipe and erase the orignal 512KB blocks>Modified your writing files(4KB) in the cache and move it back to the sector
That means if more writing operation,the SSD and NAND/eMMC do more above action=>then it will decrease the performance
How does trim doing to solve it?
Trim work like a maid of your SSD/NAND/eMMC controller
when you deleted the files,it will just marked the block which need to wiped for writing operation and it will wait until the system idle for doing the above action silently
trim also work like a recycler and ,it could told the eMMC/SSD/NAND control to wipe and controlled each sector blocks more effective(no need to move any unrelated or random blocks for each new writing operation) and decrease the searching time for th
Why we cannot be trim?
As My mention at first paragraph due to the superbrick workaround
the erase function has been disable in the kernel(remember our eMMC support trim!)
to bring back the trim work it need to reenable the erase function
Trim require erase function work as well
even we have secure erase bug,it could still using non-secure erase for trim to work
Does it means there was no solution to brick back the trim
the answer is No,
Luckly some xda menber already know about this and try to workaround to bring back trim function work
which call Project BricksBUGS
http://forum.xda-developers.com/andr...ering-t2823051
I have already adding the fstrim to the kernel even to the Rom
Does it means it could doing?
No,As I mention the erase function didn't enable(No one intended to do also)
,so you cannot use trim function
not relation with your android version,
Someone said 4.3 or higher cannot run Lagfix and will got operation was not support at endpointed devices
that is incorrect,
Because Google just implement the automatic trim,which was calling fstrim to do such function started at 4.3 while the users was idle.
if the kernel has disabled the require feature,even it have any binaries,it doesn't mean trim can work no matter any android version you have.the function was provide by hardware requirement and Kernel,not the system itself
That means it require our SGR Kernel experts to concern and reenable about it
if we need trim you have to re-enable the erase
For workaround to bring back function
please follow the project brickbug.(it need to modified the)
http://forum.xda-developers.com/andr...ering-t2823051
But our devices was affected by brick bugs,It still safe to trim
Maybe. Folklore says no,For me,I will says you should know that any action which will touch the internal setting was your own risk it could cause your devices broke down,
Also If I need to choose for performance but will have risk to brick and stable but slower than unsual
I will choose the first one,because even you got the safe as brick risk,but slower can let the phone more unstable than brick risk
it will affected our daily usage than just a brick
but according my test result,trim can bring back it was safe
Let me do an experements without the samsung patch
I have tested with 4.0.4(Official ICS TGY-ZSLPD)(no any patch!,just rooted)
Without the patch you could run the trim correctly
When you are using the Lagfix or terminal with busybox which installed fstrim
It has been test more than a months already,I have been schedule fstrim each days,it still fast as when I buying this phone
Sometime I may doing trim more than one time at one days too
I"m not sure other SGR buddy would same as my result,(no data lost or brick)
but I would say,according my result I would support to bring back the trim for our devices as experiments
if you are worrying don't do any roots even trim
Important Documents for Kernel Developer
Project BricksBUGS by @Lanchon
http://forum.xda-developers.com/andr...ering-t2823051
0 commentaires:
Enregistrer un commentaire