| To: | Steve Lord <lord@xxxxxxx> |
|---|---|
| Subject: | Re: Work Items for XFS port (UPDATED) |
| From: | "Andi Kleen" <ak@xxxxxxx> |
| Date: | Fri, 28 Apr 2000 01:51:58 +0200 |
| Cc: | "Andi Kleen" <ak@xxxxxxx>, Jim Mostek <mostek@xxxxxxx>, linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <200004272228.RAA02893@xxxxxxxxxxxxxxxxxxxx>; from lord@xxxxxxx on Thu, Apr 27, 2000 at 05:28:16PM -0500 |
| References: | <ak@xxxxxxx> <200004272228.RAA02893@xxxxxxxxxxxxxxxxxxxx> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
On Thu, Apr 27, 2000 at 05:28:16PM -0500, Steve Lord wrote: > I did try out a couple of things after you last mentioned this, but I never > managed to find anything which was slow to interrupt. This rather implies > that you have a very long running system call stuck in xfs, I suspect the > problem is not so much that we do not pay attention to interrupts, but that > something is taking much longer than it should. It is possible you found > another case of the missing run_task_queue(&tq_disk). Do things behave > better if you have activity in other filesystems on going at the same time? Yes, getdents is not interruptible. /xfs contains some very long directories, which can take a lot of time to readdir(). At least my find passes big buffers to it, so it has lots of space to play with. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | TAKE - delayed allocation, Ananth Ananthanarayanan |
|---|---|
| Next by Date: | Major milestone in endian work, Ken McDonell |
| Previous by Thread: | Re: Work Items for XFS port (UPDATED), Steve Lord |
| Next by Thread: | DM-API? Re: XFS for Linux, Lindanne Metley |
| Indexes: | [Date] [Thread] [Top] [All Lists] |