From: Artem Bityutskiy <dedekind@infradead.org>
To: Cal Page <pagcal@runbox.com>
Cc: ubifs <linux-mtd@lists.infradead.org>
Subject: Re: ubifs: partition won't mount: duplicate sqnum in replay ???
Date: Tue, 30 Dec 2008 17:29:50 +0200 [thread overview]
Message-ID: <1230650990.30332.24.camel@sauron> (raw)
In-Reply-To: <495A0FE4.4010603@runbox.com>
On Tue, 2008-12-30 at 07:11 -0500, Cal Page wrote:
> I'm running ubi at 2.6.27.4, ubifs is a mix of that base plus some
> 2.6.21 as the vfs interface changed. There are only three mtd calls you
> make, so that rev just isn't important. The base kernel, and most of vfs
> is at 2.6.19.
You finally gave us some information, although obscure. What I
understood, you have 2.6.19. Then I would expect you to port everything
we have in our ubifs-v2.6.21.git tree to your tree. Never done this
myself.
A do not know what you mean by "rev just isn't important", but the
kernel version does matter a lot. There may be various subtle things
related to core kernel changes.
We do not test back-port trees extensively, so you should do this
yourself. Try to run "integck -n0" for few days for example. Run other
tests which you may find in mtd-utils.git/tests/fs-tests/ or in
ubifs-userspace.git/tests/.
> I did not initialize the nand for the unit in question. It could have
> been the problem. I'll re-format it and start again. But, for testing,
> we have a 'crasher' device that randomly crashes the file system to
> force us into difficult recoveries. In short, for ubifs to be shipped,
> it must survive and re-mount AFTER EVERY CRASH, period.
>
> The only other problem is that ubifs takes way too much memory. We run
> for a few days on our 1 gb nand, and then the oom_killer gets called and
> down we go. What exactly was done in later releases to fix this? I need
> to back-port a solution before we ship.
I'm not sure if you'll be able to back-port patches which allow
registering the shrinker to your tree. You may try. But what can be don
is you can hack UBIFS and call the shrinker yourself when amount of
znodes becomes larger than a certain limit, so you will prevent TNC from
growing too much.
However, I'm not 100% sure it is TNC who is guilty.
Could you please send the output of:
* cat /proc/slabinfo
* cat /proc/slab_allocators
to see RAM which object are there and who allocates them. To have the
latter, you should have 'CONFIG_SLABINFO' enabled.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2008-12-30 15:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-30 12:11 ubifs: partition won't mount: duplicate sqnum in replay ??? Cal Page
2008-12-30 12:27 ` Artem Bityutskiy
2008-12-30 15:29 ` Artem Bityutskiy [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-12-30 18:32 Cal Page
2008-12-31 17:14 ` Artem Bityutskiy
2008-12-29 15:54 Cal Page
2008-12-30 8:51 ` Adrian Hunter
2008-12-30 11:48 ` Artem Bityutskiy
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=1230650990.30332.24.camel@sauron \
--to=dedekind@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=pagcal@runbox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox