[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100102221857.GA2901@elte.hu>
Date: Sat, 2 Jan 2010 23:18:57 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Andi Kleen <andi@...stfloor.org>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Christian Kujau <lists@...dbynature.de>,
Alexander Beregalov <a.beregalov@...il.com>,
Chris Mason <chris.mason@...cle.com>
Subject: Re: reiserfs broken in 2.6.32 was Re: [GIT PULL] reiserfs fixes
* Andi Kleen <andi@...stfloor.org> wrote:
> > I only have reiserfs partitions in my laptop and my testbox,
> > nothing else. And that because I'm now maintaining it de facto.
>
> AFAIK it's widely used in SUSE installations. It was the default for a long
> time.
>
> And right now as in 2.6.32 it's in a state of "may randomly
> explode/deadlock". And no clear path out of it. Not good.
Btw. that's quite weird as nothing of substance happened in fs/reiserfs in
v2.6.32:
$ git shortlog v2.6.31..v2.6.32 fs/reiserfs/
Alexey Dobriyan (2):
const: make struct super_block::dq_op const
const: make struct super_block::s_qcop const
( There might be VFS core interactions perhaps - but nothing i've seen seems
to correlate with your claims and that's quite weird. )
There's always reports about filesystem corruptions (file data cache is
statistically the most likely thing to get corrupted by borderline hw failures
such as RAM failures or DMA corruptions), but i've seen nothing out of the
ordinary for v2.6.32 with reiserfs. (and the v2.6.33-rc1 bits are not yet
merged in distro kernels)
So please substantiate your claims: URLs, distro bugzilla entries, etc.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists