yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] chrone:
Aha, thanks for the correction. :)

I didn't know what makes things faster here, but still, I do notice a difference when trimming system, data, and cache altogether.

I also noticed that vold trimmed data, cache and persist partitions.

Sent from my Nexus 4
[Samsung Galaxy Nexus] denzel09:
Thanks
[Samsung Galaxy Nexus] sanvic15dj:
Hi, My eMMC chip in GNEX is fried, I got to know about the eMMC chip and the issue with the device after I got the issue. I want to now replace the same, how do I find the Type of chip and the FeVer so that I can replace. Is VYL00M compatible with V3U00M? where can I buy the same and suggest the tools required to replace the same.
[Samsung Galaxy Nexus] markop90:
My results now are higher than yours, 6gb of free space :
[Samsung Galaxy Nexus] chrone:
thanks for this! :)

after reading your suggestion i did a quick read on http://code.google.com/p/android/issues/detail?id=39154, http://wiki.debian.org/SSDoptimization, and https://patrick-nagel.net/blog/archives/337. discard option has its up and down.

for others reading this, please be careful, you might brick your eMMC by doing the discard route. just be careful!

i guess fstrim is a safer bet, have to dig google to run this fstrim on android device. hehe :D do you happen to know how to run a schedule fstrim on gnex each midnight?

whoa nice result there. i couldn't manage to pass 7MBps (sequential write) and 0.25MBps (random write) marks. :D
[Samsung Galaxy Nexus] alangrig:
How did you manage to achieve it?
[Samsung Galaxy Nexus] seriousia:
Here's mine xD :D
[Samsung Galaxy Nexus] ph4zrd:
Maybe using a cron app or something similar...

I think some other things would also be very interesting. It seems that phones with this problem all have similar eMMC chips and production dates (type V3U00M and date around 8/2012). Maybe some of you could post their eMMC chip type and date of production or simply a screenshot of the eMMC brickbug check app (like the ones in the Google Code thread on code.google.com/p/android/issues/detail?id=39154) to verify this.

You may also get this information using the following commands in a shell:

su
cd /sys/class/block/mmcblk0/device
cat name date fwrev

Example output of my phone which had the problem:

V3U00M
08/2012
0xd

Another question would be if there are really some Galaxy Nexus devices with the infamous hard-brick bug in their eMMC chip's wear-leveling algorithm. Hopefully that was only my own fear when thinking about Samsung, eMMC and TRIM ;) (I wrote comments #25, #28, #29, #31 and #37 on the Google Code page)
[Samsung Galaxy Nexus] markop90:
Mounted data and cache with discard option and then cleaned free space with forever gone
[Samsung Galaxy Nexus] chrone:
Will look further once i have free time. This is getting interesting. ;)

Is this with fsync off?

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] seriousia:
Yes with fsync off
[Samsung Galaxy Nexus] alangrig:
So I've changed kernel
[Samsung Galaxy Nexus] markop90:
Fake results/fsync off... This doesn't solve the problem
[Samsung Galaxy Nexus] ph4zrd:
It seems that Samsung began to use other eMMC chips for the GNex GSM since around September 2012.

According to the Thread posted below, in April 2012 the majority of i9250 phones used chips of type VYL00M, the ones affected by this bug seem to have V3U00M chips...

xdaforums.com/showthread.php?t=1617710
[Samsung Galaxy Nexus] alangrig:
Well in addition, there is Chainfire apk as well which check whether our emmc is subjected to brick issue or not.

http://xdaforums.com/showthread.php?t=1693704
[Samsung Galaxy Nexus] chrone:
It seems all the writing and reading are done in RAM. :)

Thanks for this. Fortunately, my eMMC is not affected. :D

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] ph4zrd:
Did it show "unknown" or just that your eMMC is not affected?

And what was the chip type shown? V3U00M?
[Samsung Galaxy Nexus] chrone:
It said VYL00M rev. 0x25.

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] ph4zrd:
Thank you.

I assume you didn't experience these really horrible slow-down issues (phone nearly unusable, many ANRS, all apps more or less hanging for several seconds, etc.) as reported by some others here and on the Google bug report?

Although good to hear that TRIM also brings benefits with other eMMC chips.
[Samsung Galaxy Nexus] Kurre:
My results...chip VYL00M, atm about 3,5GB of free space (was down to 2 IIRC) and lousy benchmark results :eek:

I'll be doing factory reset/full formatting/clean install of run in couple of days..I'll report afterwards if I'll see any changes.

Sent from my slimbeaned GNex :)
[Samsung Galaxy Nexus] Cilraaz:
I see a lot of mention of VYL00M. Does anyone know if discard is safe with SEM32G (Verizon CDMA version)? I checked a few eMMC threads and a quick Google search and didn't find anything about it.
[Samsung Galaxy Nexus] mert2go:
Getting funny results with miui :eek:
[Samsung Galaxy Nexus] chrone:
There's a tool from Chainfire long time ago which could help identifying your eMMC but it got retracted from Play Store.

Sorry can't help you much if it's fried already. Perhaps you could go to nearest Samsung Service Center in your country to do the job.

Sent from my Nexus 4
[Samsung Galaxy Nexus] ashclepdia:
Are u certain it's not recoverable?

Isn't there an omapFlash tool somewhere on here that supposed to fix things like this?
[Samsung Galaxy Nexus] akash3656:
If its fried like mine did, you have to replace the motherboard. OR at least that is what Samsung did when I sent mine back for service. Thank God the emmc derped within the 1 year warranty period so Samsung replaced the motherboard without charging me.

---------- Post added at 12:41 PM ---------- Previous post was at 12:39 PM ----------

I tried that, it didn't work for me sadly. It was a bit of a pain to get the OMAP drivers installed though. But still it didn't revive my phone back then. :crying:
[Samsung Galaxy Nexus] seriousia:
Is it possible to make our gnex NAND F2FS ???
[Samsung Galaxy Nexus] chrone:
I'd like to know too. I'm no developer, but hope Moto will release the open source version of Moto X's f2fs. Hope Moto G will use f2fs too. Hehe

Sent from my Nexus 4
[Samsung Galaxy Nexus] cmavr8:
EDIT: Ooops just realized I was in the wrong subforum. Sorry... you can ignore or follow the thread here: http://xdaforums.com/nexus-4/general/random-write-low-trim-t2690707

"Hi, I've been having lags on my stock-rom, rooted, xposed installed Nexus 4 16GB.

So I installed lagfix and ran androbench before and after (rebooted too).

Random Write is stuck at ~0.34.

People are reporting a value around 1.00 as normal for my device.

Any ideas?

Thanks,

Chris"
[Samsung Galaxy Nexus] chrone:
how many free available storage left? try to free 25% (4GB) of your total storage for garbage collection.
[Samsung Galaxy Nexus] cmavr8:
Replying at the other thread, to avoid more OT posts :P
[Samsung Galaxy Nexus] seriousia:
If i leave only 4 gb free space trimming doesn't help in 4.3.

Does the same problem exist in kitkat also?
[Samsung Galaxy Nexus] Jar3112:
4.5 Gb free, cm11 and Franco kernel.

I get 0.84 random write and 15 sequential write with androbench.

Can't upload the screen though

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] chrone:
Up to 1mbps rw is normal as i recall. Only on particular device and filesystem that the rw would go higher near 3mbps as in Moto X and Moto G.

Sent from my Nexus 5
[Samsung Galaxy Nexus] Jar3112:
I remember achieving up to 1,5 with dirty V..

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] herpez:
Hi.

Is supposed to android 4.3 fix this problem with trim? I have a faulty chip and the true is that neither android 4.4 fixed it neither Custom kernels like fancy.

Only after i installed this tool it was fixed...

And by the way, in faulty galaxy nexus converted to f2fs we still need to use trim?

Thanks
[Samsung Galaxy Nexus] chrone:
Can't say for sure about the f2fs. But if you leave your device charged while sitting idle for 1 hour or more, it might trigger the fstrim function.

Your mile may vary since the fstrim function is built inside another maintenance function and needs to meet certain criteria for it to trim the emmc.

Thanks God lagfix fixed your issue.

Sent from my Nexus 5
[Samsung Galaxy Nexus] herpez:
Not only fixed but also saved my device. Was totally unusable...
[Samsung Galaxy Nexus] z3r0_x:
F2FS is not compatible with FSTRIM as far as I know and doesn't need it

Gesendet von meinem Nexus 4 mit Tapatalk
[Samsung Galaxy Nexus] Loureiro:
AFAIK f2fs uses something like garbage collector, trim is not needed anymore
[Samsung Galaxy Nexus] pecana:
Hi Man,

The file is no more availbale :(

Could you please reshare it?

What does it fix on the fstrim init.d script?

THANK YOU
[Samsung Galaxy Nexus] shadowfox87:
Is there a current fix for emmc brick bug on using this ftrim method from fastboot mode?
[Samsung Galaxy Nexus] xaifer:
I have a Galaxy Nexus Maguro with the defective chip V3U00M. If I use a rom f2fs I won't all the problems I have now with ext4 (I have to constantly use lagfix)?
[Samsung Galaxy Nexus] chrone:
None that I know of.

No need on f2fs.

Sent from my Nexus 5
[Samsung Galaxy Nexus] ImTheDroid:
Hey can anyone please tell me if formatting my device to F2FS will increase it performance?

I think my device is too slow compare to when I bought it. I don't know why but whatever ROM I use it just not feel that much responsive not even on JB 4.3 ROM. :(
[Samsung Galaxy Nexus] Djalaal:
F2FS helped speed up my phone a lot. I don't ever wanna go back.

However, kernels always play a big factor as well in how fast your phone is. ROM does too, but in my experience to a lesser degree as long as it is cooked up by a person who knows what he's doings.

Just a fair warning though, you loose all your data in the process. Including internal memory.
[Samsung Galaxy Nexus] GorfDroid:
If you're willing to be risky, turn off Fsync as well. I got a good performance booth without it. But you will compromise your data if anything is being written during a power failure.
[Samsung Galaxy Nexus] seriousia:
Hey

According to this patch

It introduces FITRIM in f2fs_ioctl.

Do anyone know if its already included in our kernel?

http://www.gossamer-threads.com/lists/linux/kernel/2012038#2012038
[Samsung Galaxy Nexus] chrone:
whoa so there is now trim function on f2fs, great catch! :)

i don't know whether f2fs is solid stable as of now, but the new moto x 2014 ditched it and switched back to ext4. afaik, f2fs was created by samsung, and i never read samsung really use that one up on its premium android phone.

i had experienced using f2fs on the original moto g and f2fs did smooth things out a bit though the device was sorely ran out of ram quickly and things got reloaded each time which was a bummer for multitasking with more than 4 apps opened. it's a nice phone though.
[Samsung Galaxy Nexus] chrone:
No need in L on N5 if you regularly left your device charged at midnight and it's in idle state. Android 5.0.2 should make fstrim more aggressive on reboot if fstrim not triggered after 3 days.

Resource:

http://www.androidpolice.com/2014/1...r-android-5-0-1_r1-lrx22c-to-5-0-2_r1-lrx22g/
[Samsung Galaxy Nexus] fifthelement:
There is a much better app than lagfix to trim manually. free, ad-free with schedules and lollipop support : https://play.google.com/store/apps/details?id=com.fifthelement.trimmer
[Samsung Galaxy Nexus] seriousia:
Still nothing for f2fs
[Samsung Galaxy Nexus] fifthelement:
f2fs doesnt need trimming.
[Samsung Galaxy Nexus] chrone:
thanks for pointing this out, i've included this on page one. :good:
[Samsung Galaxy Nexus] GtrCraft:
The init.d script doesn't work for me. Tried on a N7 2012 running 5.1.1
[Samsung Galaxy Nexus] chrone:
you won't need to run all of this on 5.1.1, since android does trim the emmc each reboot as i recall aosp changelog on 5.0.2 onward. :D
[Samsung Galaxy Nexus] Abu-khulzat:
Does this also apply to other devices running Android 5.0.2+?

I have note 5 on Android 5.1.1, do I have this fstrim on reboot?
[Samsung Galaxy Nexus] chrone:
It should be. If not, bad move from Samsung. :D
[Samsung Galaxy Nexus] ph4zrd:
Found a post referencing it in connection with the eMMC bug.

xda-developers - View Single Post - Samsung working on Emmc brick fix

Probably wouldn't recommend it now.
[Samsung Galaxy Nexus] chrone:
yeah, lucky me it only slowed down to more less 5Mbps when it reached the write provisioning.

i know androbench only tests /data by default, never tried to use other partition from its settings and see how it goes with /sdcard.

you're the same as me. i'll live with 5Mbps write speed though. :D

you could try the suggested app by alangrig to see whether your eMMC is affected or not, "Got Brickbug ?" made by Chainfire.

not having enough permission to see your result, dude. :)

I updated first post with work around posts from you guys. Thanks! :)
[Samsung Galaxy Nexus] ph4zrd:
The results will be the same, probably a bit lower, as on GNex /sdcard is bound to /data/media using some fuse magic :)

I think the app will show "unknown chip" as the SEM32G chip isn't mentioned in the description and/or changelog.

After reading some posts about the chips affected by the brick bug and looking at the kernel source code provided by Samsung (the brick bug fix) and our source code, I'm somewhat sure that

1) the brick bug fix is not in our kernel (probably not needed, means also that using discard on bad chips may brick the phone) and

2) the SEM32G is NOT affected by the brick bug and only needs some quirks when using discard which ARE part of our kernel source.

So using the trick on SEM32G should be safe.

Link to block.c/mmc_fixup struct in CM10 mmc driver, i9250 kernel
[Samsung Galaxy Nexus] Cilraaz:
Thanks for the info. That didn't come up in my searching.

As ph4zrd said in the post after yours, it just shows "unknown chip".
[Samsung Galaxy Nexus] chrone:
Oops, my bad. What's your write speed result when the storage is nearly full? Hope it's still in the 5Mbps range.

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] Cilraaz:
I'm at roughly half full storage (14.78GB available). I ran an Androbench and got:

Seq Read: 26.96MB/s

Seq Write: 5.44 MB/s

Rand Read: 7.29 MB/s - 1868.76 IOPS (4k)

Rand Write: 0.17MB/s - 43.98 IOPS (4k)

SQLite Insert: 32.61 TPS, 9.98 sec

SQLite Update: 30.04 TPS 9.98 sec

SQLite Delete: 35.47 TPS, 8.45 sec

It's the random write that concerns me. Frankly. I'm not yet seeing any day-to-day impact, but that number is just awful.
[Samsung Galaxy Nexus] markop90:
I can confirm...
[Samsung Galaxy Nexus] chrone:
Yeah your numbers seems about right. You won't notice the difference when transferring big files from pc to your gnex unless you use stopwatch, but you'll notice a massive long transfer time when transferring lots of small files. The small random write performance may introduce you to occasional system hiccups if the system or particular apps need to write random small data (file system journaling, or database related). :D

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] ph4zrd:
For science. V3U00M. Of course mounted with -o discard ;)

Before: only 870.5MB free...

Androbench results: 1) 870 MB free; 2) 1.1 GB free; 3) 1.8 GB free
[Samsung Galaxy Nexus] Kurre:
Well I made clean install (with some exaggeration) by firstly doing oem lock/unlock procedure, then flashing stock 4.1.2 rom (system, radio, userdata) via fastboot, booting up, flashing TWRP, wiping everything again, installing SlimBean 3.1 and franco.Kernel r300. And what was the result..same lousy benchmark like before..with about 12GB of free space.

Now results with AndroBench:

SR: 25.74 MB/s

SW: 6.59 MB/s

RR: ?? MB/s (1896.88 IOPS(4K))

RW: ?? MB/s (68.81 IOPS(4K))

Previously:

SR: 25.61 MB/s

SW: 5.68 MB/s

RR: 7.28 MB/s (1864.11 IOPS(4K))

RW: 0.24 MB/s (63.56 IOPS(4K))

So I gained only few percents with this procedure..But afterall system feels snappier (most probably, because I got rid of all **** I had in my phone :p )
[Samsung Galaxy Nexus] tiny4579:
Just a random question related to the low random write scores. I thought flash memory was supposed to be better with random I/O than sequential I/O. Why does the eMMC exhibit the exact opposite behavior?
[Samsung Galaxy Nexus] chrone:
Yeah, your numbers are the same with stock, and with the snappier response perhaps is due to less processes running less random read and write. :D

In theory yes, in real life i had some flashdrives which perform worst or better with random read and write. The only advantage is with the latency compared to mechanical drive.

I found freiya slc chipset had the best performer random io on usb2.0 flash drive, or with a quad channel mlc nand chipset.

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] alangrig:
So I've done some research today early in the morning.

I have run androbehch with almost free internal memory, fully one and emptied one again. The results are as follows:

1. Androbench on almost free internal memory:

View attachment 1540977 View attachment 1540978

2. Androbench with full memory:

View attachment 1540981 View attachment 1540982

3. Andorbench after deleting copied previously files:

View attachment 1540983 View attachment 1540984

4. Androbench after REBOOT (deleting copied previously files)

5. Summary:

As you can see, performance haven't significantly decreased in all cases. In real life I even haven't felt speed decrease at all.

Now I am going to perform full factory reset with PIT file via Odin, flash latest Google Stock image and post results here.
[Samsung Galaxy Nexus] chrone:
Well done! :)

Yeah the synthetic benchmark only slows down a bit, perhaps we get good eMMC chipset while others don't, or Google has added something to reduce this slow down write performance on Android 4.2.x.

I'll try to run a test too with full storage later and post it here. :)

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] alangrig:
Mine Gnexus is from batch production 07/2012.
[Samsung Galaxy Nexus] krugdenis:
07/2012 is not affected by this bug. Only 08/2012 and maybe newer.
[Samsung Galaxy Nexus] Spacefish:
I just flashed the stockimage via fastboot on my GNex, i only get 0,2Mbyte / sec RW and 54 IOPS/sec (5.36 MB/sec Seq Write) as opposed to others that got 3 times more. I have a VYL00M Chip with production Date 03/2012 FW 0x25.

The Phone feels slow, google now for example sometimes just hangs and aborts when using speed input, and that after a clean fastboot flash.

What is the normal result for a stock NNex without any modified kernels or something like that?
[Samsung Galaxy Nexus] alangrig:
Well,

All above mine research results were done on stock image.

Now I've performed clean install from the ground and right away installed only one app Androbench and run micro test again. Here are results

View attachment 1541664

Finally, as for me you can see there is no difference at all: full, wiped, deleted, copied. Speed is always the same.
[Samsung Galaxy Nexus] chrone:
me: 05/2012.

around 7Mbps for sequential write and 0.25Mbps for random write: http://www.anandtech.com/show/6130/the-16gb-nexus-7-storage-performance

i filled up my gnex on android 4.2.1, deleted the files to free up some storage cured the slow write performance. system still feels snappy. yay! :D

initial capacity before filling up, 9GB available:

SW: 6.5Mbps

RW: 0.25Mbps

almost full capacity used, 384MB available:

SW: 3.9Mbps

RW: 0.24Mbps

after delete some files, 9GB available, with or without reboot afterward:

SW: 6.9Mbps

RW: 0.24Mbps

Sequential Write took the hit, most noticeable when transfering files to gnex, While Random Write seemed slow down a bit, not significant. System was still responsive both before and after filling up, and after freeing up some space.

Screenshots as in post #1. Kudos to Android 4.2.1! :D
[Samsung Galaxy Nexus] chrone:
Nice data, dude! At least only small portion of users who use almost all of their storage capacity.

Your sequential write speed is awesome, class 10 flashdrive to achieve above 10Mbps mark. And as for the system responsiveness, the random write speed seemed not affected much too. :)

Update:

This just in. Check this article from anandtech: Exploring the Relationship Between Spare Area and Performance Consistency in Modern SSDs.

Keeping your storage at 25% available will make the storage sub-system performance more consistent on SSD, I believe eMMC using same NAND chipset as in SSD less the controller. :D

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] markop90:
Today, after some time with /data and /cache mounted with discard option by an init.d script, my phone began to slowdown again, with 4GB of free space... Used Forever Gone again, useless... guys I had enough of this problem!!! :(

GOOGLE DO SOMETHING DAMMIT!!!!
[Samsung Galaxy Nexus] chrone:
So sorry to hear that. Seems this bug affects newest eMMC chip severely. :confused:

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] geoffcorey:
After reading someone in the trinity kernel thread was having slow down issues similar to those described in this thread, he said after changing his readahead value to 128, his phone's responsiveness improved drastically.

I too have tried this, and it seems to have brought a new life to my phone.

As for how to change this value, I have no idea off the top of my head, but some have suggested the trickstermod app. I used the trinity kernel app after flashing the trinity kernel.
[Samsung Galaxy Nexus] zetsumeikuro:
It's the nature of the beast and a technological limitation sadly. Just keep some drive space open and you'll be ok.
[Samsung Galaxy Nexus] Android addiction:
Could there be an danger to the phone having it at 128kb ?
[Samsung Galaxy Nexus] chrone:
It's ok as long as fsync on.

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] Android addiction:
Awesome checked my kernels settings insured fsync was on, set readahead to 128k. Been running for a couple hours now and definitely am noticing it. Thanks guys.
[Samsung Galaxy Nexus] tiny4579:
Isn't 128kb readahead stock? And fsync off should be faster but more likely to cause data corruption.
[Samsung Galaxy Nexus] Android addiction:
Stock Franco kernels are set to 2048 As a reference .
[Samsung Galaxy Nexus] Ashtrix:
This thread is very useful , thanks guys :good: !!!
[Samsung Galaxy Nexus] Robca79:
I ran the got brick bug app from the play store. It said no that my chip wasn't affected. I have SEM32G. I have the verizion galaxy nexus. So does this mean that I won't get slowed performance?
[Samsung Galaxy Nexus] chrone:
The got brick bug app is to get to know whether your eMMC chip is affected by the brick bug or not, and it gets nothing to do with the slow down performance bug. The brick bug happens when you flash or tweaking its mounting option and your phone dies because of one of them.

You could always benchmark your storage using androbench app from gplay when your storage is empty, half full, near full, and full. If near full or even full you get slow down, then your nand chip is affected.

My chip is only having insignificant slow down when it reaches near full or even full. But newer chip is reported having significant slow down write performance.

Hope this helps. :)

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] Ashtrix:
Shame on google , shipping their flagship nexus phones with dangerous bugs :eek: (AMOLED's & now eMMC chips ) !
[Samsung Galaxy Nexus] KaiZ51:
I have 3GB of free space and I still don't get the full performance that I should get.

Anyway, not sure if this has been posted yet, but here's the link to the issue in Google tracker: http://code.google.com/p/android/issues/detail?id=39154

It needs to get more stars so that it gets Google's attention and they fix this damn bug, try to spread it around guys.