|
2014-10-24
, 15:10
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#12
|
It just means that the filesystem has added them to its list, and is avoiding them. I think it's likely the case every single N900 in existence has some bad blocks, even from the factory.
The Following 4 Users Say Thank You to javispedro For This Useful Post: | ||
|
2014-10-24
, 18:36
|
Posts: 330 |
Thanked: 556 times |
Joined on Oct 2012
|
#13
|
Yes, every N900 has bad blocks from the factory. However, as said, the eMMC is the one doing wear level and error correction. If you're seeing "bad blocks" at the filesystem level, something is broken, period. No one's N900 is "silently corrupting" data every so often.
You're seeing what looks very much like random read errors, which points to cables or contact points or sth else like that. The kernel message log (ie dmesg) will have additional info.
|
2014-10-25
, 16:03
|
Posts: 330 |
Thanked: 556 times |
Joined on Oct 2012
|
#14
|
|
2014-10-26
, 10:54
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#15
|
The Following 3 Users Say Thank You to shadowjk For This Useful Post: | ||
|
2014-10-26
, 14:49
|
Posts: 330 |
Thanked: 556 times |
Joined on Oct 2012
|
#16
|
As for typical dd and emmc, keep in mind that the typical block size is much larger than filesystem blocksize. The physical block, when erased, can only be written to once, before it must be erased again.
What does this mean for badblocks? If a read test finds 1k bad, and you avoid using that sector, but write to anywhere else inside same physical block, it will put that physical block aside, and copy contents to a new one, along with the requested modification. The bad sector is now invisible, but will reappear elsewhere once that same physical block comes up in rotation again.
What's the size of the physical block? That's vendor proprietary and secret information. On the order of 512k to 16M though.
As for edt2 vs ext3, in my experience, ext2 is slower, which suggests it's triggering many read-modify-write cycles, causing excessive write amplification.
|
2014-10-26
, 15:09
|
Posts: 330 |
Thanked: 556 times |
Joined on Oct 2012
|
#17
|
|
2014-10-26
, 16:39
|
|
Posts: 6,446 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#18
|
The Following User Says Thank You to pichlo For This Useful Post: | ||
|
2014-10-26
, 18:24
|
Posts: 330 |
Thanked: 556 times |
Joined on Oct 2012
|
#19
|
That depends on the block size (the -bs parameter). It is generally a good idea to set it as large as possible, MMC or not.
BTW I am not sure about erase blocks going as large as shadowjk indicated. Wikipedia mentions sizes up to 512kB, although it may not be entirely up to date. 16MB seems a bit excessive.
I usually set the block size (-bs) to something between 1 and 4 MB, depending on how I feel on the day. YMMV.
|
2014-10-26
, 21:15
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#20
|
The Following User Says Thank You to shadowjk For This Useful Post: | ||
The key (which in hindsight is quite logical) is to run fsck.ext3 after mkfs.ext3, and to run it with the -c flag (very important).
What the -c flag in fsck.ext3 does is to check for bad blocks and add them to the bad blocks list. This means you are "blanking out" the bad blocks from the point of view of the filesystem, thereby creating a virtual eMMC without error.
My mistake was believing that simply running mkfs.ext3 with the -c flag would be enough. It is not. You need to run fsck.ext3 with the -c flag a few times, until no bad blocks are reported.
Then, run fsck.ext3 a few more times without the -c flag. Reboot the N900, and run again.
The exact invocation line I used is:
fsck.ext3 -vfc /dev/<your_partition>
Then, when no bad blocks are reported,
fsck.ext3 -vf /dev/<your_partition>
(NOTE: Omitting the -a flag in both command lines above is on purpose, as I didn't want to automatically answer "yes" to all questions, and I wanted to see what was going on. Doing this, however, will be time consuming and tedious if there is a lot of issues to change, especially when a large number of errors is found. Once you are comfortable, it's probably better to add the -a flag as well).
In my experience, you can get to a point where this last command keeps reporting the same error (for example, invalid inode_resize). When that happens, reboot the N900 and run it again.
I don't know if this kind of thing is implemented to run in the background in the default configuration. But if you change the partition table (especially if you add custom partitions that are not in the default configuration) you should probably run these checks.
Out of the 2 ext3 partitions I was testing yesterday, I could only copy 1 instance of the large file in the second partition, and none in the first partition.
I just copied 2 instances of the large 3GB file to each partition, and successfully ran md5sum on each of those instances.
And, I'd like to add that it's not a bad idea to do this, as if you get some bad sectors that your filesystem can't account for, you will lose data (and you won't even realize it's happening).
To check if you have bad blocks (just using the read test), the command is (as root):
badblocks -b 1024 -sv /dev/<your_partition>
If for some reason your partition has blocks of size other than 1024 bytes, change it. -sv is what I use in order to get verbose feedback in the terminal as the command is running. Don't be startled if you see bad blocks. But if you do, it's time for some fscking
And, if your ext3 system reports no bad blocks, it doesn't mean the eMMC has no bad blocks. It just means that the filesystem has added them to its list, and is avoiding them. I think it's likely the case every single N900 in existence has some bad blocks, even from the factory.
Last edited by malfunctioning; 2014-10-24 at 00:01.