ubifs: partition won't mount: duplicate sqnum in replay ???

Artem Bityutskiy dedekind at infradead.org
Tue Dec 30 10:29:50 EST 2008


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 (Битюцкий Артём)




More information about the linux-mtd mailing list