Re: frequent kernel BUG and lockups - 2.6.39 + xfs_fsr

From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Cc: Marc Lehmann <schmorp@schmorp.de>
Subject: Re: frequent kernel BUG and lockups - 2.6.39 + xfs_fsr
Date: Wed, 10 Aug 2011 08:59:26 +0200	[thread overview]
Message-ID: <201108100859.27576@zmi.at> (raw)
In-Reply-To: <20110809111526.GA7631@schmorp.de>

[-- Attachment #1.1: Type: Text/Plain, Size: 2332 bytes --]

On Dienstag, 9. August 2011 Marc Lehmann wrote:
> On Tue, Aug 09, 2011 at 12:10:48PM +0200, Michael Monnerie 
<michael.monnerie@is.it-management.at> wrote:
> > First of all, please calm down. Getting personal is not bringing us
> > anywhere.
> 
> Well, it's not me who's getting personal, so...?

A single rant from a dev shouldn't hurt one too much. He might have been 
sitting in front of some code during 72 hours, his eyes already being in 
16:9 format staring at a weird bug... It's OK to strike back once, but 
then be cool again and work at the problem.

> As has been reported on this list, this option is really harmful on
> current xfs - in my case, it lead to xfs causing ENOSPC even when the
> disk was 40% empty (~188gb).

Was this the "NFS optimization" stuff? I don't like that either.

> Well, if it were one fragment, you could read that in 4-5 seconds, at
> 374 fragments, it's probably around 6-7 seconds. Thats not harmful,
> but if you extrapolate this to a few gigabytes and a lot of files,
> it becomes quite the overhead.

True, if you have to read tons of log files all day. That's not my 
normal use case, so I didn't bother about that until now.

> That allocsize option is no longer reasonable with newer kernels, as
> the kernel will reserve 64m diskspace even for 1kb files
> indefinitely.

Just "as long as the inode is cached" or something, I remember that 
"echo 3 >drop_caches" cleans that up. Still ugly, I'd say.

> If you find a way of recreating files without appending to them, let
> me know.

Seems we have a different meaning of "append". For me, append is when an 
existing file is re-opened, and data added just to the end of it.

> > And maybe he could use it for optimizations. Is there any tool on
> > Linux to record such I/O patterns?
> 
> I presume strace would do, but thats where the "lot of work" comes
> in. If there is a ready-to-use tool, that would of course make it
> easy.

It's a pity that such a generic tool doesn't existing. I can't believe 
that. Doesn't anybody have such a tool at hand?

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

// Haus zu verkaufen: http://zmi.at/langegg/

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs