lkml.org 
[lkml]   [2002]   [Aug]   [5]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 5 Aug 2002 11:22:49 +0200 (CEST)
FromRoland Kuhn <>
SubjectRe: reiserfs blocks long on getdents64() during concurrent write
Hi!

On Mon, 5 Aug 2002, Oleg Drokin wrote:

> Hello!> > On Sun, Aug 04, 2002 at 06:09:34PM +0200, Roland Kuhn wrote:
> > > The first call to getdents64 takes 4.7s! I captured the task status and 
> > got this:> > It seems that your kernel performs writes slowly.> 
That's true only in the case of a "filled write queue" (I don't know 
exactly how it's working). However, I verified that the average SCSI 
command takes less than two seconds to complete in this case (time between 
send to card and receive response interrupt).

BTW: was it directly clear for you for what the do_journal_begin_r() was 
waiting? I'm not so familiar with fs coding, especially the locking...

While we're at it: it looks like e.g. the 3ware driver is busy waiting in
tw_scsi_queue() until (by virtue of an interrupt?) a request_id becomes
free. Is this common practice? Or is there code somewhere checking for the
availability of these request slots before calling scsi_queue? I would
think that the CPU can do more useful things while waiting for an
interrupt...

> > this is to use a sync mount, and there I discovered something really 
> > strange: 2.4.19 gives me about 17MB/s while 2.4.18-3 (RedHat) was creeping 
> > slow with 10kB/s!> > 2.4.18-3 is particularly bad know for this exact problem (slow write speed),
> you should consider upgrading to at least 2.4.18-5 kernel from redhat updates.
> > For me on plain 2.4.18 the problem is not visible that bad as for you.
> I.e. ls on a directory where I write this big file finishes in under
> half a second.> 
Do you use IDE or SCSI? It seems like the SCSI drivers can have up to 
255*256 sectors pending on the controller. If that's the problem, how can 
I decrease this buffering?

> > If you have any thoughts on the cause of this behaviour and/or on how to 
> > fix it, I would be glad to hear them. If it's not too complicated I could 
> > even code something up myself, and I for sure can do any testing needed.> > You said 2.4.19 writes stuff faster for you, how about testing ls on that
> kernel?> 
The call trace was from 2.4.19, and the situation actually was much better 
than in the 2.4.18-3 case, where it took about 1 minute for ls to come 
back. 

Ciao,
					Roland

+---------------------------+-------------------------+
|    TU Muenchen            |                         |
|    Physik-Department E18  |  Raum    3558           |
|    James-Franck-Str.      |  Telefon 089/289-12592  |
|    85747 Garching         |                         |
+---------------------------+-------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:27    [from the cache]
©2003-2008