| To: | Zlatko Calusic <zlatko.calusic@xxxxxxxx> |
|---|---|
| Subject: | Re: xfsdump stuck in io_schedule |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Fri, 15 Nov 2002 14:06:35 +0100 |
| Cc: | Andi Kleen <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <dnlm3v9ebk.fsf@xxxxxxxxxxxxxxxxx> |
| References: | <dnfzu3yw8u.fsf@xxxxxxxxxxxxxxxxx> <20021115135233.A13882@xxxxxxxxxxxxxxxx> <dnlm3v9ebk.fsf@xxxxxxxxxxxxxxxxx> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.22.1i |
> I agree. What points me to this list is that I observed such behavior > only with xfsdump. Although 2.5 is still in development phase, VM has > been really stable recently. But yes, it's possible that this is a > genuine kernel VM bug, and xfsdump just triggers it. I guess xfsdump pins both a lot of pages and a lot of inodes/dentries (similar to a program that opens a few thousand files and mlocks significant parts of its address space). May not be the best tested scenario in the world. It apparently is called the "google workload" (because all the hundreds of google cluster boxes run in a similar setup) and it was only fixed in 2.4 VM a short time ago. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: xfsdump stuck in io_schedule, Zlatko Calusic |
|---|---|
| Next by Date: | Re: xfsdump stuck in io_schedule, Zlatko Calusic |
| Previous by Thread: | Re: xfsdump stuck in io_schedule, Zlatko Calusic |
| Next by Thread: | Re: xfsdump stuck in io_schedule, Zlatko Calusic |
| Indexes: | [Date] [Thread] [Top] [All Lists] |