From: "Eddie Dawydiuk" <eddie@embeddedx86.com>
To: linux-mtd@lists.infradead.org
Subject: Bad Blocks...
Date: Tue, 26 Apr 2005 13:33:59 -0700 (MST) [thread overview]
Message-ID: <32985.192.168.0.136.1114547639.squirrel@oz.embeddedx86.com> (raw)
Hello Yaffers,
After running some stress tests on a 128MB NAND Flash I have found some
strange behavior while using the Yaffs filesystem... The stress test
creates a ring-buffer of 5 directories, each directory contains 10,000
files with a size of 1248 bytes (Please find the source code attached).
When running this application on a 32MB NAND Flash I am able to fill the
disk and then delete the files as expected... Although when running the
test on a 128MB NAND Flash(with the same kernel) I find that after
creating slightly over 35,000 files I am unable to write any more files to
disk(my board hangs). After rebooting the board, when I attempt to delete
the files only some of the files are deleted successfully(on the first
attempt). After attempting several more times I am able to delete all of
the files but I find that I have hundreds of bad blocks(there are no error
messages when I attempt to delete a file and it is unsucessfully deleted).
I have provided the output of /proc/yaffs below(after running the stress
test multiple times) and am using a 2.4.26 kernel... I have read the other
posts refering to bad block management
(http://www.aleph1.co.uk/pipermail/yaffs/2005q1/000955.html) and have
ensured the fixes suggested have been made. If anyone has any suggestions
I would appreciate them...
$ cat /proc/yaffs
YAFFS built:Apr 26 2005 10:44:45
$Id: yaffs_fs.c,v 1.3 2005/01/25 00:38:25 eddie Exp $
$Id: yaffs_guts.c,v 1.41 2005/04/24 08:54:36 charles Exp $
Device yaffs
startBlock......... 1
endBlock........... 7999
chunkGroupBits..... 2
chunkGroupSize..... 4
nErasedBlocks...... 1575
nTnodesCreated..... 35000
nFreeTnodes........ 21790
nObjectsCreated.... 34400
nFreeObjects....... 21795
nFreeChunks........ 142801
nPageWrites........ 71420
nPageReads......... 2573700
nBlockErasures..... 4021
nGCCopies.......... 317
garbageCollections. 3599
passiveGCs......... 3599
nRetriedWrites..... 0
nRetireBlocks...... 2397
eccFixed........... 0
eccUnfixed......... 0
tagsEccFixed....... 0
tagsEccUnfixed..... 654
cacheHits.......... 0
nDeletedFiles...... 22161
nUnlinkedFiles..... 22162
nBackgroudDeletions 0
useNANDECC......... 1
Thanks,
Eddie
next reply other threads:[~2005-04-26 20:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-26 20:33 Eddie Dawydiuk [this message]
2005-04-26 22:43 ` Bad Blocks Charles Manning
-- strict thread matches above, loose matches on Subject: below --
2004-04-01 14:06 Bad blocks Kalev Lember
2004-04-01 14:36 ` David Woodhouse
2004-04-02 0:14 ` Greg Ungerer
2004-04-04 11:16 ` Kalev Lember
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32985.192.168.0.136.1114547639.squirrel@oz.embeddedx86.com \
--to=eddie@embeddedx86.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox