yashsingh1/xdaforums huggingface dataset:
[Epic 4G General] h2g2:
There is no clear answer. Samsung in all likelihood does what most chipmakers do which is to test the chips during the QA process and if the number of errors exceed some threshold, they either ship it, bin it, scavenge it or toss it. I don't know what these numbers are and it's probably classified data for Samsung.

The number is also variable depending on the quality of the yields (this tends to go up over time but sometimes you have bad batches here and there).

In some ways, it's like asking "how fast should I be able to overclock my processor" - an 800Mhz processor that is stable at 1.2Ghz was pulled from a higher quality batch than the 800Mhz processor that is only stable up to 1Ghz. But the chipmaker only tested for stability at 800Mhz. The overclocking headroom is just a matter of chance.
[Epic 4G General] hydrogenwv:
h2g2 - Well put. Even the person with 15 bad blocks may have had 15 bad blocks from the beginning. And, assuming they test each chip, they might just check to ensure it works and may not check the number of bad blocks.

As has been pointed out, change over time is much more important than a snapshot in time. Maybe this thread could be stickied (Maybe eliminate the RFS vs. EXT4 line in the title) so it doesn't fall into oblivion and we could *possibly* get some great data.
[Epic 4G General] DiGi760:
Just had another epic in my hands that has been active since September. It has been odined 2 or 3 times today, and hasn't had any roms flashed to it. It has always been on RFS and was still on DI18 when brought here. It had only 1 bad block.
[Epic 4G General] Dameon87:
Not flamin at all but this overall test is worthless.

As has been said, chips can ship with bad blocks.

Also the fact that people have had their phones for different periods of time, done different things with them, and use them differently is not a good grounds for a test.

Also, this does kind of prove to an extent that noob was wrong. As he said it would be months of using ext4 that would kill our nand. So far there is no evidence that our phone is going to die any quicker.

I personally only have 7 bad blocks. And I've probably flashed and odined more than quite a few of you combined, in addition to having ext4 on my phone atleast 2 days prior, with lots of tests both before and in between.
[Epic 4G General] hayabusa1300cc:
Got it november 8

Flashed and odin many times

Now running ext 4 since release

export PATH=/data/local/bin:$PATH:.

$ $ cat /proc/L*/bmlinfo

FSR VERSION: FSR_1.2.1p1_b139_RTM

minor position size units id

1: 0x00000000-0x00040000 0x00040000 1 0

2: 0x00040000-0x00080000 0x00040000 1 1

3: 0x00080000-0x00a80000 0x00a00000 40 20

4: 0x00a80000-0x00bc0000 0x00140000 5 3

5: 0x00bc0000-0x00d00000 0x00140000 5 4

6: 0x00d00000-0x01200000 0x00500000 20 21

7: 0x01200000-0x01980000 0x00780000 30 6

8: 0x01980000-0x02100000 0x00780000 30 7

9: 0x02100000-0x12d80000 0x10c80000 1074 22

10: 0x12d80000-0x32f80000 0x20200000 2056 23

11: 0x32f80000-0x3de80000 0x0af00000 700 24

12: 0x3de80000-0x3eb00000 0x00c80000 50 11

(0)(0) bad mapping information

No BadUnit RsvUnit

0: 1023 4090

1: 1238 4089

2: 1330 4088

3: 2479 4087

4: 2584 4086

5: 2872 4085

$
[Epic 4G General] hydrogenwv:
Dameon - The test is not worthless, it just tells us nothing at the moment. That doesn't mean it has no merit. Over time, if folks keep periodically posting their # of bad blocks, it'll provide the ability to compare the changes.

By your logic, we should never do prospective studies, because the initially collected data tells us nothing. That's not a good way to think.

Edit: Furthermore, we might find that EXT4 is BETTER for the NAND than RFS, In which case the results could give us the ability to extend the life of our devices by switching to EXT4. I'm not taking sides on which is better, but knowing for sure can't hurt, right?
[Epic 4G General] plapczyn:
It doesn't prove anything sir. The sample size is too low. What is does show is that there isn't any significant difference in bad blocks YET. We will only know over time.
[Epic 4G General] Dameon87:
If you do not test the INITIAL amount of bad blocks, then test again right before you were to put ext4 on the phone, and the again at some other interval then the test IS worthless.

You have to have test groups and control groups.

If someone flashes 10 times a day, vs another person who flashes once a day, and the person who flashes more has more dead blocks but, then it tells you nothing.

Preliminary results of a test with no standards means nothing... even over time these results will get worse.

If you had 2 people who tested at 0 bad blocks each, have had their phones for 3 weeks each. Then had one flash to ext4, while the other stayed on rfs, not flashing or using odin anytime after, then you would have semi-reliable results.

You cannot judge results which have no common similarities, have different usage patterns, and owned the device for varying amounts of time.

I am all for prospective studies, but even prospective studies have control factors.
[Epic 4G General] plapczyn:
FSR VERSION: FSR_1.2.1p1_b139_RTM

minor position size units id

1: 0x00000000-0x00040000 0x00040000 1 0

2: 0x00040000-0x00080000 0x00040000 1 1

3: 0x00080000-0x00a80000 0x00a00000 40 20

4: 0x00a80000-0x00bc0000 0x00140000 5 3

5: 0x00bc0000-0x00d00000 0x00140000 5 4

6: 0x00d00000-0x01200000 0x00500000 20 21

7: 0x01200000-0x01980000 0x00780000 30 6

8: 0x01980000-0x02100000 0x00780000 30 7

9: 0x02100000-0x12d80000 0x10c80000 1074 22

10: 0x12d80000-0x32f80000 0x20200000 2056 23

11: 0x32f80000-0x3de80000 0x0af00000 700 24

12: 0x3de80000-0x3eb00000 0x00c80000 50 11

(0)(0) bad mapping information

No BadUnit RsvUnit

0: 1831 4090

1: 3898 4089

2: 3998 4088

You must note that nearly everyone will have a few bad blocks, especially people that have done a lot of flashing like say devs and flashwhores. This is normal of flash technology. I believe the spec said it has a 3% area allocated for bad sectors, so that's around 15MB. 15MB / 128 KB block size = 120 reserve blocks. This whole debate reminds me of the final episode of dollhouse...which it shouldn't.
[Epic 4G General] Dameon87:
Ext4 is using a 4KB blocksize. Not sure about rfs.
[Epic 4G General] hydrogenwv:
Dameon - I agree, it's not perfect. We'll never be able to control everything. Studies like this happen in real life all the time and are very useful, as long as you consider the possible confounders. You are right, we'll never be able to control everything, but, inevitably, people will stick with RFS and some will go to EXT4. The number of bad sectors before switching to EXT4 is irrelevant, because the change itself isn't going to hurt any blocks. We can get useful results by just looking over time.. For instance:

Person 1-50: RFS, mean bad blocks now = 5, mean bad blocks in a month = 7

Person 51-100: EXT4, mean bad blocks now = 3, mean bad blocks in a month = 10

That tells us something... Now, we could also consider the number of times each person flashed over that month and separate the users into different "Flash frequency" categories. With enough data, we can get VERY useful results. Calling the test worthless is just going to cause people to stop 'wasting their time' providing useful data.
[Epic 4G General] victorythagr8:
export PATH=/data/local/bin:$PATH

$ $su# cat /proc/L*/bmlinfozb

/proc/L*/bmlinfozb: No such file or directory

# cat /proc/L*/bmlinfo

FSR VERSION: FSR_1.2.1p1_b139_RTM

minor position size units id

1: 0x00000000-0x00040000 0x00040000 1 0

2: 0x00040000-0x00080000 0x00040000 1 1

3: 0x00080000-0x00a80000 0x00a00000 40 20

4: 0x00a80000-0x00bc0000 0x00140000 5 3

5: 0x00bc0000-0x00d00000 0x00140000 5 4

6: 0x00d00000-0x01200000 0x00500000 20 21

7: 0x01200000-0x01980000 0x00780000 30 6

8: 0x01980000-0x02100000 0x00780000 30 7

9: 0x02100000-0x12d80000 0x10c80000 1074 22

10: 0x12d80000-0x32f80000 0x20200000 2056 23

11: 0x32f80000-0x3de80000 0x0af00000 700 24

12: 0x3de80000-0x3eb00000 0x00c80000 50 11

(0)(0) bad mapping information

No BadUnit RsvUnit

0: 2954 4090

1: 3154 4089

2: 3284 4088

3: 3772 4087

#
[Epic 4G General] ghostrid3r:
cat /proc/L*/bmlinfo
FSR VERSION: FSR_1.2.1p1_b139_RTM
minor position size units id
1: 0x00000000-0x00040000 0x00040000 1 0
2: 0x00040000-0x00080000 0x00040000 1 1
3: 0x00080000-0x00a80000 0x00a00000 40 20
4: 0x00a80000-0x00bc0000 0x00140000 5 3
5: 0x00bc0000-0x00d00000 0x00140000 5 4
6: 0x00d00000-0x01200000 0x00500000 20 21
7: 0x01200000-0x01980000 0x00780000 30 6
8: 0x01980000-0x02100000 0x00780000 30 7
9: 0x02100000-0x12d80000 0x10c80000 1074 22
10: 0x12d80000-0x32f80000 0x20200000 2056 23
11: 0x32f80000-0x3de80000 0x0af00000 700 24
12: 0x3de80000-0x3eb00000 0x00c80000 50 11

(0)(0) bad mapping information
No BadUnit RsvUnit
0: 281 4090
1: 1023 4089
2: 3167 4088

Oct. 5

RFS

rooted/flashed rarely

Mammon_Bonsai4All_V1.1.3
[Epic 4G General] xjman:
So far I see no discernable difference. Ill check mine on rfs tonight.
[Epic 4G General] dr_gibberish:
I DO think there is one thing we learn from even this preliminary data, and that is EXT4 is not immediately, seriously damaging to the phone. That is of course what everyone has said all along, but it is nice to see that running it a few days certainly has not resulted in dramatically more bad blocks.

That said, the real test will be looking at the same phones in a month or two. FYI, I have had my phone since launch day, pretty minimal flashing in that time (and maybe 4 uses of Odin) and I have two bad sectors. Unless I see dramatic change in a month, I am going to stay on EXT4 as I am eligible for an upgrade at the end of August anyhow.
[Epic 4G General] h2g2:
There are a couple of problems with this. The main issue is that wear on the blocks is ultimately dependent on the usage pattern of the disk. The file system in question will add some overhead for e.g. volume and file metadata. They key is to make sure you're comparing results where the usage patterns are similar. If you have an EXT4 user who is syncing only email with one account vs. an RFS user who is syncing five different accounts, the extra disk activity for the RFS user may result in a greater increase in bad blocks over a period of time but this does not prove anything with regards to whether RFS or EXT4 generates more overhead.

The other issue is that flash frequency isn't really a useful metric. You're talking about a largely sequential operation that doesn't involve a lot of block rewrites (and, in fact, both RFS and EXT4 avoid block rewrites anyway - actually, I may have misspoken on this. I'll need to do more research.) so flashing isn't going to result in a big impact on the lifespan of the OneNAND. Heavy SQLite activity, for example, is a better thing to look at but those metrics are difficult to collect. Ideally, you'd want to log the number of transactions and weigh the number of bad blocks accordingly to see if there's a deviation between RFS and EXT4 but it's not even clear if those metrics are obtainable (I admit that I haven't looked into this, so if someone knows more about this, I'd love to hear it).

Personally, what I'd do is to set up a Linux VM with two disks, one formatted with EXT4 and one with RFS. Then, run the same usage pattern on each and then look at the VM metrics to tell me how much actual IO load was generated on each. That would tell me how much actual overhead either file system generates.

The harder thing to quantify is the quality and effectiveness of the wear leveling. Dynamic wear leveling, which is what RFS and EXT4 implement, isn't that great to begin with and testing this basically involves filling up a flash disk to some capacity and then writing data over and over until the chip dies. If one file system does better wear leveling than the other, you should see a significant deviation in the scores.

But it's largely moot because RFS isn't available to end users for testing purposes. EXT4 is, but without a baseline to compare it to, the results would be meaningless.
[Epic 4G General] Dameon87:
I do agree. I am no scientist, but I do know a lot about how tests are done, and how factors have to be correct.

But already we are missing some very key information from 1/2 the people who have posted results.

Timeframe of purchase, whats FS they are using, how long, etc.

I just don't find this to be an accurate test. IF the same people keep post results over the course of lets say... 3-6 months, then we MIGHT get a general idea at decay rate, but that is about it. And even that will be questionable, as 90% of people can't even guesstimate how many times they have flashed.
[Epic 4G General] edonnelly:
I do a lot of scientific studies, and I'll tell you the first thing you need to know is what question you are trying to answer.

This whole set of threads came about from a thread that stated "EXT4 is dangerous on OneNAND" and that it was a "very bad idea to put ext4 on oneNAND."

Addressing whether or not those statements are warranted or not is much different from addressing "are there subtle differences between RFS and EXT4" in terms of the long-term life of oneNAND.

The first is analogous to "Is this drug dangerous and should the FDA step in and ban this drug?" while the second is more similar to "Here are two very similar drugs, which one is slightly more effective or has a slightly lower risk of side-effects?"

My gut feeling is that the thread started out addressing the first, but has morphed into a discussion of answering the second.
[Epic 4G General] heathmcabee:
# cat /proc/L*/bmlinfo

cat /proc/L*/bmlinfo

FSR VERSION: FSR_1.2.1p1_b139_RTM

minor position size units id

1: 0x00000000-0x00040000 0x00040000 1 0

2: 0x00040000-0x00080000 0x00040000 1 1

3: 0x00080000-0x00a80000 0x00a00000 40 20

4: 0x00a80000-0x00bc0000 0x00140000 5 3

5: 0x00bc0000-0x00d00000 0x00140000 5 4

6: 0x00d00000-0x01200000 0x00500000 20 21

7: 0x01200000-0x01980000 0x00780000 30 6

8: 0x01980000-0x02100000 0x00780000 30 7

9: 0x02100000-0x12d80000 0x10c80000 1074 22

10: 0x12d80000-0x32f80000 0x20200000 2056 23

11: 0x32f80000-0x3de80000 0x0af00000 700 24

12: 0x3de80000-0x3eb00000 0x00c80000 50 11

(0)(0) bad mapping information

No BadUnit RsvUnit

0: 715 4090

1: 1135 4089

2: 1720 4088

3: 1724 4087

#

Running EXT4 for 5 days, got this phone as a refurb from Sprint on 12/22.
[Epic 4G General] quik99:
have had my epic for a month ext4 since it came out 0 bad blocks
[Epic 4G General] JMMusic:
I've had my Epic for about two weeks. I've never flashed anything. I am on bone stock 2.1 and have been contemplating flashing but was waiting for 2.2 before taking the plunge. I haven't even rooted it (though I do have z4root installed... literally just waiting to push the button...).

Copied from ConnectBot, so lost the first column as too close to the edge of the screen. :)
[Epic 4G General] daddymikey1975:
You should compile these in the first post.
[Epic 4G General] jocala:
# cat /proc/L*/bmlinfo
FSR VERSION: FSR_1.2.1p1_b139_RTM
minor position size units id
1: 0x00000000-0x00040000 0x00040000 1 0
2: 0x00040000-0x00080000 0x00040000 1 1
3: 0x00080000-0x00a80000 0x00a00000 40 20
4: 0x00a80000-0x00bc0000 0x00140000 5 3
5: 0x00bc0000-0x00d00000 0x00140000 5 4
6: 0x00d00000-0x01200000 0x00500000 20 21
7: 0x01200000-0x01980000 0x00780000 30 6
8: 0x01980000-0x02100000 0x00780000 30 7
9: 0x02100000-0x12d80000 0x10c80000 1074 22
10: 0x12d80000-0x32f80000 0x20200000 2056 23
11: 0x32f80000-0x3de80000 0x0af00000 700 24
12: 0x3de80000-0x3eb00000 0x00c80000 50 11

(0)(0) bad mapping information
No BadUnit RsvUnit
0: 796 4090
1: 1023 4089
2: 1250 4088
3: 1448 4087
4: 2429 4086
5: 3086 4085
#

Running leaked DK28 with original RFS. I've lost count of how many times I've flashed this phone. A bunch.
[Epic 4G General] gTen:
Well thats actually why in my post I included the time I bought the phone so that others would too..

If we really want to use this research data we would have to take notes of how much bad blocks we have now (and assuming we dont swap our file system)..take results every month and compare them..

Overall though we would probably only be seeing results in months at best..by which time it would be moot for our epics....but I guess it will be an indicator once we get our NEXT pones and figure out what FS to go with lol
[Epic 4G General] tatoniss:
Got mine on launch day. Running ext4

$ export PATH=/data/local/bin:$PATH

$cat/proc/L*/bmlinfo

cat/proc/L*/bmlinfo: not found

$cat /proc/L*/bmlinfo

FSR VERSION: FSR_1.2.1p1_b139_RTM

minor position size units id

1: 0x00000000-0x00040000 0x00040000 1 0

2: 0x00040000-0x00080000 0x00040000 1 1

3: 0x00080000-0x00a80000 0x00a00000 40 20

4: 0x00a80000-0x00bc0000 0x00140000 5 3

5: 0x00bc0000-0x00d00000 0x00140000 5 4

6: 0x00d00000-0x01200000 0x00500000 20 21

7: 0x01200000-0x01980000 0x00780000 30 6

8: 0x01980000-0x02100000 0x00780000 30 7

9: 0x02100000-0x12d80000 0x10c80000 1074 22

10: 0x12d80000-0x32f80000 0x20200000 2056 23

11: 0x32f80000-0x3de80000 0x0af00000 700 24

12: 0x3de80000-0x3eb00000 0x00c80000 50 11

(0)(0) bad mapping information

No BadUnit RsvUnit

0: 284 4090

1: 312 4089

2: 1023 4088

3: 1330 4087

4: 2045 4086

5: 2804 4085

6: 2936 4084

7: 3178 4083

8: 3228 4082

9: 3300 4081

10: 3754 4080

$
[Epic 4G General] ecooce:
Since Ive had my phone for 3 months,lets say it came with bad blocks,and or RFS caused the 7 bad blocks I have,(lets call the 4 days on EXT4 a wash),if after 3 more months on EXT4 I have 14 or less (flashing ROMs just as much) then we can say EXT4 is safe for ME.If after 3 months on EXT4 I have 100 bad blocks (flashing ROMs just as much) then I would say EXT4 is bad for ME....So Ill keep up the results,maybe once a week...Yes there are plenty of variables which make these early results worthless,over time you should still see a pattern that will give you a guesstimation (real word) of what RFS does and what EXT4 does,which is actually acceptable in the scientific world,because there are things that just need to be guesstimated,and I think we are smart enough to see a pattern in the results...So all in all the tests are not really worthless at all,maybe the early tests,Ill give you that.But over time we will clearly see some diffrence. If all the people on EXT4 for 3 months have over say 200 bad blocks,and people on RFS that either flash often or dont, only have 15 bad blocks,we will know EXT4 is killing OneNAND faster.
[Epic 4G General] ungovernable1977:
Had this new replacement for about two weeks, no ext4, flashed one dk28 rom

This is interesting, but sooo many factors, I think we will better see how solid the nand media is in general, but im curious to see after time how we are affected. Think I will flash ext4 just to see if theres a jump... idunno. Thanks for finding probably the most concrete method we can for this, Noobnl... Theories are great... but evidence is better.

export PATH=/data/local/bin:$PATH

$ cat /proc/L*/bmlinfo

FSR VERSION: FSR_1.2.1p1_b139_RTM

minor position size units id

1: 0x00000000-0x00040000 0x00040000 1 0

2: 0x00040000-0x00080000 0x00040000 1 1

3: 0x00080000-0x00a80000 0x00a00000 40 20

4: 0x00a80000-0x00bc0000 0x00140000 5 3

5: 0x00bc0000-0x00d00000 0x00140000 5 4

6: 0x00d00000-0x01200000 0x00500000 20 21

7: 0x01200000-0x01980000 0x00780000 30 6

8: 0x01980000-0x02100000 0x00780000 30 7

9: 0x02100000-0x12d80000 0x10c80000 1074 22

10: 0x12d80000-0x32f80000 0x20200000 2056 23

11: 0x32f80000-0x3de80000 0x0af00000 700 24

12: 0x3de80000-0x3eb00000 0x00c80000 50 11

(0)(0) bad mapping information

No BadUnit RsvUnit

0: 181 4090

1: 3738 4089

$
[Epic 4G General] dr_gibberish:
You are totally correct with this. Not only did we start out trying to answer question one, I think it is really the question of interest to 99% of us. I would say the results so far do NOT support the idea that EXT4 is somehow immediately dangerous to the oneNAND. Whether there are subtle differences is a much more difficult case to prove, but I am unconcerned. If the phone lasts at least another year, I will have moved on to another model.
[Epic 4G General] ungovernable1977:
These results arent worthless, but any postulations based on them may be... Its actually good to start testing this soon after ext4 was an option, so those with it can get a pretty good idea of what its doing, eventually

OK so everyone who is just writing in their numbers, if you use Terminal Emulator, you can hit menu, email yourself the results, then cut and paste from there. I think the actual results may be more important as time goes on, so the actual data would be handy. Also, if someone IS going to compile this and categorize flashwhores, medium, and root only users, it would help to add that in each of your results post. This actually seems like a good idea, and Daemon, dont take it personally... its already looking as if the damage done (if it shows to be there) is over a time period that most phone junkies will give these phones to their kids for an mp3 player... but it is interesting to see an attempt at real data, not just theories, no?
[Epic 4G General] adamw1101:
If you want a true test you need to take 20 testers 10 rfs 10 ext4 do a base line test and then test for bad blocks once a week for a month and then compare results on data wear.
[Epic 4G General] ydoucare:
I've got 8 bad blocks and have only run stock rooted roms (DI18 and DK28). Got the phone in November.
[Epic 4G General] scienceguy:
My Epic, purchased 1 week after launch, running rfs- 5 bad

Son's Epic, purchased Nov. 14th, ext4 for 3 days- 13 bad

Will continue to check...as a "scienceguy" I know this is meaningless at the moment...different builds, use, etc. must also be noted.
[Epic 4G General] MДЯCЦSДИT:
$ export PATH=/data/local/bin:$PATH

$cat /proc/L*/bmlinfo

FSR VERSION: FSR_1.2.1p1_b139_RTM

minor position size units id

1: 0x00000000-0x00040000 0x00040000 1 0

2: 0x00040000-0x00080000 0x00040000 1 1

3: 0x00080000-0x00a80000 0x00a00000 40 20

4: 0x00a80000-0x00bc0000 0x00140000 5 3

5: 0x00bc0000-0x00d00000 0x00140000 5 4

6: 0x00d00000-0x01200000 0x00500000 20 21

7: 0x01200000-0x01980000 0x00780000 30 6

8: 0x01980000-0x02100000 0x00780000 30 7

9: 0x02100000-0x12d80000 0x10c80000 1074 22

10: 0x12d80000-0x32f80000 0x20200000 2056 23

11: 0x32f80000-0x3de80000 0x0af00000 700 24

12: 0x3de80000-0x3eb00000 0x00c80000 50 11

(0)(0) bad mapping information

No BadUnit RsvUnit

0: 2906 4090

1: 3066 4089

$

Rfs since September 1st flashed 3 roms
[Epic 4G General] DRockstar:
Well, this test has shown me one thing- that compared to the other results so far, the fact I test with my phone as much as I do has definitely caused more wear on my nand.

People often don't appreciate what we do in the name of the community. For version 2 of my all in one, I flashed my phone dozens of times between between Eclair & Froyo, using both Clockworkmod & Odin, testing between 3 computer operating systems in the attempt to make one solution work for everyone.

Well, I'm thinking of flashing more selectively at this point, considering I have the most bad blocks of any other post so far.

I'm not even sure my count of 15 bad blocks should even be put into the average for rfs, due to my extreme use.
[Epic 4G General] ungovernable1977:
what if it came with 12 out the door when you bought it? The averages will eventually tell you the likelihood of your bad blocks being due to testing... how about some other heavy developers???
[Epic 4G General] h2g2:
According to Samsung's specs, they build in 2% reserve space into the OneNAND chip. I believe block size on OneNAND is 4k which means for a 512MB OneNAND chip, you have 131,072 blocks total. 2% reserve will allow you to have over 2600 bad blocks before you run into any real problems.

Simply put, you (and everyone else who has been posting their results here) have nothing to worry about.

Edit: Info courtesy of plapczyn in his thread:

http://www.samsung.com/global/busin...s/fusionmemory/Products_FAQs_Reliability.html