On 11 December 2012 22:49:47 Ivan Shapovalov wrote:
> On 11 December 2012 19:33:39 Edward Shishkin 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?
>
> 12 hours of indexing, scanning, compiling, repeated execution of
> "find <mountpoint> -type f -exec grep wtf {} \;" and so on.
>
> > > 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 ;)
>
> Maybe it's actually migration who does the damage? If we don't lock the
> pages properly and they are "stolen" by the migration code... If this is
> the case, I shall eventually get corruptions with current setup (since
> migration/compaction is not disabled).
> If I get them, I'll rebuild without migration at all and will see if
> corruptions disappear completely. (Then they should disappear, if the
> prediction is true.)
...So, the kernel did not pass the overnight testing with usual errors of
"cluster corrupted" and etc (which is just as planned).
I'm now rebuilding without CONFIG_COMPACTION and CONFIG_MIGRATION.
>
> > > 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
