All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Greg Stark <gsstark@mit.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: More tests [Was: Problem with read blocking for a long time on /dev/scd1]
Date: Sun, 22 Dec 2002 21:13:45 +0100	[thread overview]
Message-ID: <20021222201345.GG30634@unthought.net> (raw)
In-Reply-To: <87of7euj51.fsf_-_@stark.dyndns.tv>

On Sun, Dec 22, 2002 at 11:13:14AM -0500, Greg Stark wrote:
> 
> I've done some more tests:
> 
> The problem still occurs with straight ide drivers, no ide-scsi
> 
> The problem still occurs with 2.4.20-ac2

Can you reproduce on 2.4.18 or 2.4.19-pre5 ?

AFAIK 2.4.X broke at 2.4.19-pre6 - something was changed that related to
the order in which read requests are scheduled.

I have a file-server here which also blocks on reads for as long as 5-10
seconds at a time - in particular when the nightly backup runs.

It's a PITA for those of us who're hit by it (imagine working in an
emacs that freezes up for 10 seconds every 10 minutes). But not a lot of
people have complained, so nobody has (again to my knowledge - please
correct if I'm mistaken) come up with a solution that was not just a
hack that for some reason which noone understands, seems to make the
problem appear less.

I would *so* love to be corrected on that one  ;)

> 
> I removed extraneous llseek syscalls from libdvdread, it's now reading purely
> sequentially and still failing. I doubt an llseek to the current location even
> gets through to the driver but I figured I would remove another variable.

Writes stall reads "almost indefinitely". It's a "feature".

If you can reproduce this in 2.4.18 (which was "invincible" as
file-server kernel for me, except that I needed newer IDE drivers for a
new Promise card and therefore had to make the switch), then I'm
completely mistaken and my ramblings have nothing to do with what you're
seeing.

Please try reproducing on 2.4.18, to confirm or deny.

> Question: Does the readahead parameter in hdparm affect accesses to the raw
> /dev/hdd device? Does it affect atapi cdrom access?

Nothing tunable cures the problem - if it is indeed the same problem you
are hit by.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

  reply	other threads:[~2002-12-22 20:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-21  0:49 Problem with read blocking for a long time on /dev/scd1 Gregory Stark
2002-12-21  1:28 ` Greg Stark
2002-12-21  6:14 ` Greg Stark
2002-12-22 16:13   ` More tests [Was: Problem with read blocking for a long time on /dev/scd1] Greg Stark
2002-12-22 20:13     ` Jakob Oestergaard [this message]
2002-12-23  8:58       ` Greg Stark
2002-12-27 15:36         ` Jakob Oestergaard
2003-01-08  4:03         ` Jakob Oestergaard
2002-12-23 18:02 ` Problem with read blocking for a long time on /dev/scd1 Krzysztof Halasa
  -- strict thread matches above, loose matches on Subject: below --
2003-01-08 12:03 More tests [Was: Problem with read blocking for a long time on /dev/scd1] Andrey Borzenkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021222201345.GG30634@unthought.net \
    --to=jakob@unthought.net \
    --cc=gsstark@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.