ubifs: partition won't mount: duplicate sqnum in replay ???
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.
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.
Cal Page
Quoted 4 lines · Cal Page
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.
Not sure I understand this.
Quoted 5 lines
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.
Fair enough. We did similar tests at our side.
Quoted 1 line
The only other problem is that ubifs takes way too much memory.
You use olde kernel, and UBIFS shrinker is disabled there, which means that it never flushes the TNC cache. This is noted here:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_source
Quoted 4 lines
We run
for a few days on our 1 gb nand, and then theoom_killergets 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.
The TNC shrinker is registered. See 'ubifs_shrinker()'.
Signature · 2 lines
Best regards, Artem Bityutskiy (Битюцкий Артём)
Quoted 4 lines · Cal Page
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/.
Quoted 10 lines
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_killergets 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.
Signature · 2 lines
Best regards, Artem Bityutskiy (Битюцкий Артём)