[Top] [All Lists]

Re: xfsdump stuck in io_schedule

To: Stephen Lord <lord@xxxxxxx>, Andrew Morton <akpm@xxxxxxxxx>
Subject: Re: xfsdump stuck in io_schedule
From: Zlatko Calusic <zlatko.calusic@xxxxxxxx>
Date: Sun, 17 Nov 2002 15:40:18 +0100
Cc: Andi Kleen <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <1037539697.1240.30.camel@xxxxxxxxxxxxxxxxxxxxxxx> (Stephen Lord's message of "17 Nov 2002 07:28:17 -0600")
References: <dnfzu3yw8u.fsf@xxxxxxxxxxxxxxxxx> <20021115135233.A13882@xxxxxxxxxxxxxxxx> <dnlm3v9ebk.fsf@xxxxxxxxxxxxxxxxx> <20021115140635.A31836@xxxxxxxxxxxxx> <dnr8dmj1i1.fsf@xxxxxxxxxxxxxxxxx> <20021115164012.A28685@xxxxxxxxxxxxx> <87u1ih4x29.fsf@xxxxxxxxxxxxxx> <1037539697.1240.30.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: zlatko.calusic@xxxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-debian-linux)
Stephen  Lord <lord@xxxxxxx> writes:

> On Sat, 2002-11-16 at 04:40, Zlatko Calusic wrote:
>> Andi Kleen <ak@xxxxxxx> writes:
>> >> Hm, to tell the truth, all that doesn't sound like an easy problem to
>> >> fix, but I'm sure we'll think of something. :)
>> >
>> > It may be possible to just hack the user space program to limit 
>> > the data currently in flight, but that would likely impact performance
>> > somewhat. Better than doing no backups though.
>> Before that, I think we should try to fix it properly. Yes, xfsdump is
>> blazingly fast and probably that is the reason we have some problems
>> with it now, but let's try not to surrender before a fight. :)
> The xfsdump folks would be pleased to hear that, we get complaints the
> other way sometimes.

Hm, I find that quite strange. I've just tested xfsdump vs tar and
xfsdump is ~50% faster.

> You say you are dumping into a file in another filesystem, what type of
> filesystem is it? If you stream data there from something like lmdd
> does it work OK? Also (and I am not sure you can do this), what happens
> if you xfsdump to /dev/null? 

Wow, that was a couple of good questions. I'm dumping to a xfs
filesystem. I tried tarring instead of dumping, and voila:

tar: page allocation failure. order:0, mode:0x0
tar: page allocation failure. order:0, mode:0x0

So it is really not xfsdump specific. It's strange how I haven't
noticed such a problem before, but IIRC, I used cp -a during
conversion of ext3 partitions to xfs. It might be connected to a fact
that I'm writing to a BIG file and/or to a slower disk?!

Second thing, dumping to /dev/null goes without a problem, no messages
in kernel log, everything's just fine.

Let's recapitulate:

I'm dumping (or tarring) xfs filesystem (/usr) which consists of lots
of files from a faster (7200rpm, plate speed up to 37MB/sec) IDE disk
to a (big = 2 - 3GB) file on a xfs partition on a slower (5400rpm,
plate speed up to 23MB/sec) IDE disk and I'm getting page allocation
failures during that exercise. Kernel is virgin 2.5.47, preempt is
off, number of processors doesn't make a difference.

Now, more than ever, this looks like a VM bug, not really xfs
specific. Andrew, what would you like me to try to clarify it further?

Stephen, thanks for help.

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