| To: | Andi Kleen <ak@xxxxxxx> |
|---|---|
| Subject: | Re: xfsdump stuck in io_schedule |
| From: | Zlatko Calusic <zlatko.calusic@xxxxxxxx> |
| Date: | Sat, 16 Nov 2002 11:40:30 +0100 |
| Cc: | linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <20021115164012.A28685@xxxxxxxxxxxxx> (Andi Kleen's message of "Fri, 15 Nov 2002 16:40:12 +0100") |
| References: | <dnfzu3yw8u.fsf@xxxxxxxxxxxxxxxxx> <20021115135233.A13882@xxxxxxxxxxxxxxxx> <dnlm3v9ebk.fsf@xxxxxxxxxxxxxxxxx> <20021115140635.A31836@xxxxxxxxxxxxx> <dnr8dmj1i1.fsf@xxxxxxxxxxxxxxxxx> <20021115164012.A28685@xxxxxxxxxxxxx> |
| 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) |
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. :) -- Zlatko |
| Previous by Date: | [Bug 195] New: xfs_fsr results in oops, bugzilla-daemon |
|---|---|
| Next by Date: | Re: xfsdump stuck in io_schedule - st driver pinning, Zlatko Calusic |
| Previous by Thread: | Re: xfsdump stuck in io_schedule, Andi Kleen |
| Next by Thread: | Re: xfsdump stuck in io_schedule, Stephen Lord |
| Indexes: | [Date] [Thread] [Top] [All Lists] |