From: Artem Bityutskiy <dedekind@infradead.org>
To: Bruce_Leonard@selinc.com
Cc: linux-mtd@lists.infradead.org
Subject: Re: MTD/flash perfomance statistics
Date: Tue, 02 Dec 2008 11:26:19 +0200 [thread overview]
Message-ID: <1228209979.5029.45.camel@sauron> (raw)
In-Reply-To: <OFD5C7E2A2.7ED96530-ON88257508.0065AD14-88257508.0066ADDB@selinc.com>
On Fri, 2008-11-21 at 10:41 -0800, Bruce_Leonard@selinc.com wrote:
> Okay, a bit more info has trickled in from the application guys. We don't
> know exactly what we want, but something is better than nothing :). What
> we're looking for is information regarding how often we're
> reading/writting the flash, how many factory bad blocks there are, how
> many bad blocks have developed over time.
Well, this should be MTD feature, not UBI/UBIFS feature. And if you want
to preserve I/O statistics over reboots, you have to save it on flash,
which is not light-weight anymore.
> We want to be able to make a
> rough estimate of how long a part is going to last, based on the part
> itself (i.e., number of bad blocks)
There is maximum erase counter available in /sys/class/ubi/ubi0/max_ec,
which you may use to judge how close the flash to EOL.
/sys/class/ubi/ubi0/bad_peb_count - count of bad PEB on the MTD device
this UBI device sits on. It includes both factory-marked and dynamically
appeared. There is way to distinguish between factory and non-factory
bad blocks in MTD.
/sys/class/ubi/ubi0/reserved_for_bad tells you number of eraseblocks
reserved for bad block handling. If it becomes zero, you may have
troubles when the next bad block appears, so you may watch this value as
well.
> and any given customer's usage of the
> product (i.e., how often is the part being accessed, how many new bad
> blocks have developed, how well is the UBI wear leveling working)
Well, it is easy to add more statistics, but preserving it between
reboots is not easy.
> wich
> will vary from customer to customer depending on how they're using the
> product. It doesn't have to be anything sophisticated and I think
> primarily what the app guys are after are things that UBI probably already
> tracks for the wear leveling (i.e., number of writes and bad blocks).
Well, loot at the above sysfs-provided info, may be it is enough?
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
prev parent reply other threads:[~2008-12-02 9:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-11 18:08 MTD/flash perfomance statistics Bruce_Leonard
2008-11-12 5:38 ` Artem Bityutskiy
2008-11-12 8:30 ` Bruce_Leonard
2008-11-17 23:42 ` Bruce_Leonard
2008-11-18 8:05 ` Artem Bityutskiy
2008-11-21 18:41 ` Bruce_Leonard
2008-12-02 9:26 ` Artem Bityutskiy [this message]
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=1228209979.5029.45.camel@sauron \
--to=dedekind@infradead.org \
--cc=Bruce_Leonard@selinc.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