Prev: [PATCH -next] libs: force lzma_wrapper to be retained
Next: staging Patch 02/03: Crystal HD
From: Ingo Molnar on 2 Jan 2010 16:50

* Andi Kleen <andi(a)firstfloor.org> wrote:

> On Sat, Jan 02, 2010 at 09:11:39PM +0100, Frederic Weisbecker wrote:
> > I've never lost any datas since I began this work. And
> > I run it every day. If I had experienced lock inversions,
> > and sometimes soft lockups, I did not experienced serious
> > damages. It's a journalized filesystem that can fixup the things
> > pretty well.
>
> So are you confident that 2.6.33 will not have regular soft-lockups for
> reiserfs users?

Well, are you confident that your hardware-poison changes in v2.6.33 will not
have any user triggerable bugs? It's a pretty silly question IMO because you
can never be 100% confident.

What matters is for the changes to be sane and clean, for there to be no known
regression and for any reported bugs to be fixed speedily. Which Frederic is
doing in an utmost excellent way ...

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 2 Jan 2010 17:30

* Andi Kleen <andi(a)firstfloor.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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: tytso on 2 Jan 2010 18:40
On Sat, Jan 02, 2010 at 10:06:55PM +0100, Frederic Weisbecker wrote:
>
> Thanks! I'm going to test it now. I've been running a stress test
> from Chris Mason which basically checks races on parallel writes/read.

Hmm, which test is this?

> If this testsuite includes more checks, like xattr and some other
> things, then that's exactly what I was searching.

Yes, quite a bit more than that. One such test (which is used by
xfsqa test) is the fsstress proram, which is quite flexible. You can
program different combinations of fallocate, direct I/O read/writes,
setxattr, buffered read/writes, symlinks, truncates, renames, etc..
The xfsqa suite will run fsstress in a number of different modes, but
that's not the only test program that it uses. It also uses the fsx
program which exercises concurrent read/write/mmap operations, as well
as other programs to test acl support, noatime support, etc.

I make a point of running the regression test suite before pushing a
patch series to Linus; it makes me far more comfortable than I haven't
accidentally introduced some problem.

> I guess this is the right place to get it?
>
> git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git

Yep. You'll need to install a number of packages to compile it,
including libaio-dev, libattr1-dev, libacl1-dev, xfsprogs,
xfslibs-dev, etc.

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christian Kujau on 2 Jan 2010 18:50
tytso(a)mit.edu wrote on 2010-01-02 15:36 :
>> Thanks! I'm going to test it now. I've been running a stress test
>> from Chris Mason which basically checks races on parallel writes/read.
>
> Hmm, which test is this?

http://oss.oracle.com/~mason/stress.sh, IIRC.

Christian.
--
make bzImage, not war
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 2 Jan 2010 20:20
On Sat, Jan 02, 2010 at 03:43:52PM -0800, Christian Kujau wrote:
> tytso(a)mit.edu wrote on 2010-01-02 15:36 :
>>> Thanks! I'm going to test it now. I've been running a stress test
>>> from Chris Mason which basically checks races on parallel writes/read.
>>
>> Hmm, which test is this?
>
> http://oss.oracle.com/~mason/stress.sh, IIRC.
>
> Christian.


That's it! It's simple script that runs concurrent copies of
a directory and that checks the coherency of the result.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [PATCH -next] libs: force lzma_wrapper to be retained
Next: staging Patch 02/03: Crystal HD