On 12/14/2012 04:14 AM, Ivan Shapovalov wrote:
On 13 December 2012 23:47:10 Edward Shishkin wrote:
On 12/11/2012 09:54 PM, Dušan Čolić wrote:
On Tue, Dec 11, 2012 at 7:33 PM, Edward Shishkin
<edward.shishkin@xxxxxxxxx> wrote:
On 12/11/2012 04:08 PM, Ivan Shapovalov wrote:
Hello!
Hello.
With help of Dušan Čolić<dusanc@xxxxxxxxx> who provided his kernel
config
diff I've found a kernel option which, when disabled, greatly reduces
(hopefully to zero, but need time to verify it) corruption rate in
reiser4.
It's CONFIG_TRANSPARENT_HUGEPAGE (or something which is used by it like
CONFIG_COMPACTION or CONFIG_MIGRATION).
For now I'm testing it with CONFIG_TRANSPARENT_HUGEPAGE disabled
How long?
For me the difference in uptime is months without vs hours with it :D
on 2.6.39.4
Hm, indeed: my setup with enabled migration can not survive even one
kernel compilation, while with disabled migration everything looks ok..
The overnight testing also showed no errors...
So shall we release reiser4-for-3.7 and announce FIXED(?) once again?
:)
I worry that migration is mandatory option for hugepages.
Does fail_migrate_page() work with hugepages?
Also before the release I'll try to take a look at this:
http://marc.info/?l=reiserfs-devel&m=135402207623711&w=2
This failed path might indicate that we adjusted to fs-writeback
incorrectly.
Edward.
Regards,
Ivan.
on kernel
3.6.10, and everything seems to be OK so far (so the workaround is
version-
agnostic).
Edward, are there any guesses on what can make reiser4 choke on
hugepages/compaction/migration?
TBH, no ideas. They (hugepages) are _transparent_.
It means we shouldn't suffer in theory ;)
I'm not even barely familiar with the kernel
internals.
Thanks,
Ivan.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
