From: Adrian Hunter <adrian.hunter@intel.com>
To: Shuah Khan <shuahkhan@gmail.com>
Cc: David Mosberger-Tang <dmosberger@gmail.com>,
dedekind1@gmail.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: UBIFS recovery taking too long
Date: Tue, 10 Dec 2013 09:25:12 +0200 [thread overview]
Message-ID: <52A6C1D8.7020900@intel.com> (raw)
In-Reply-To: <CAKocOOOT2J_+hmEsAnAJVWV7TOqgApd3Lih+3WaRob4e8Nex4Q@mail.gmail.com>
On 09/12/13 23:30, Shuah Khan wrote:
> Adding ubifs maintainers.
>
> -- Shuah
>
> On Mon, Dec 9, 2013 at 1:53 PM, David Mosberger-Tang
> <dmosberger@gmail.com> wrote:
>> I've had no luck getting any response from the linux-mtd mailing list
>> regarding the issue reported below.
>> I think it is a very serious issue since it can easily render an
>> embedded system unusable.
>>
>> --david
>>
>> ---------- Forwarded message ----------
>> From: David Mosberger-Tang <dmosberger@gmail.com>
>> Date: Thu, Nov 7, 2013 at 11:44 AM
>> Subject: UBIFS recovery taking too long
>> To: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
>>
>>
>> We recently encountered a strange issue where UBIFS recovery is
>> suddenly taking a lot longer than usual (v3.7-based kernel). In our
>> case, recovery took about 30 seconds. This caused a serious problem
>> because our watchdog timer was set to 15 seconds, effectively
>> rendering the devices unbootable.
>>
>> Does anybody know what triggers this slow recovery mode? Also, how
>> can we calculate a worst-case recovery time for a given flash
>> chip-size.
Slowness is probably caused by trying to make free space. Was the file
system very full? A smaller journal might help.
Probably the only way to determine worst-case recovery time is to test it.
Worst case conditions are likely to be a full journal and a nearly full file
system.
Ideally you want to capture a file system image that exhibits the slow
behaviour, then you can enable debug messages and see what it is doing.
>>
>> Thanks,
>>
>> --david
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
next prev parent reply other threads:[~2013-12-10 7:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 18:44 UBIFS recovery taking too long David Mosberger-Tang
2013-12-09 20:53 ` Fwd: " David Mosberger-Tang
2013-12-09 21:30 ` Shuah Khan
2013-12-10 7:25 ` Adrian Hunter [this message]
2013-12-10 18:41 ` David Mosberger-Tang
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=52A6C1D8.7020900@intel.com \
--to=adrian.hunter@intel.com \
--cc=dedekind1@gmail.com \
--cc=dmosberger@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shuahkhan@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.