xfs
[Top] [All Lists]

Re: frequent kernel BUG and lockups - 2.6.39 + xfs_fsr

To: xfs@xxxxxxxxxxx
Subject: Re: frequent kernel BUG and lockups - 2.6.39 + xfs_fsr
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 10 Aug 2011 08:59:26 +0200
Cc: Marc Lehmann <schmorp@xxxxxxxxxx>
In-reply-to: <20110809111526.GA7631@xxxxxxxxxx>
Organization: it-management http://it-management.at
References: <20110806122556.GB20341@xxxxxxxxxx> <201108091210.50204@xxxxxx> <20110809111526.GA7631@xxxxxxxxxx>
User-agent: KMail/1.13.6 (Linux/3.0.0-zmi; KDE/4.6.0; x86_64; ; )
On Dienstag, 9. August 2011 Marc Lehmann wrote:
> On Tue, Aug 09, 2011 at 12:10:48PM +0200, Michael Monnerie 
<michael.monnerie@xxxxxxxxxxxxxxxxxxx> 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: signature.asc
Description: This is a digitally signed message part.

<Prev in Thread] Current Thread [Next in Thread>