mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Andrey Borzenkov" <arvidjaar@mail.ru>
To: linux-kernel@vger.kernel.org
Cc: "Greg Stark" <gsstark@MIT.EDU>
Subject: Re: More tests [Was: Problem with read blocking for a long time on /dev/scd1]
Date: Wed, 08 Jan 2003 15:03:30 +0300	[thread overview]
Message-ID: <E18WEvi-000Epy-00@f19.mail.ru> (raw)

> 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
>
> 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.
> 
> Question: Does the readahead parameter in hdparm affect accesses to the
> raw /dev/hdd device? Does it affect atapi cdrom access?

I have seen the same phenomenon under slightly different conditions.

I am running Mandrake with supermount. In short, supermount fakes mounting device and then mounts real device on first access. On every file operation it checks for media change and invalidates and remounts media in this case.

In some cases, the best example being rpm -Uvh * on CD, this command lasts ages. The reason is long pause during file closing, as much as 5 seconds (in my case), so it takes very long time to examine all files. The device is pure IDE DVD-R (Creative) running in UDMA2 on i815e. I put timing information in ide-cd.c and ide.c and it shows that pause happens between ide_do_drive_cmd called from cdrom_queue_packet_command (from cdrom_check_status) and next corresponding ide_do_request (unfortunately, the log output happened inside of it, when request is already fetched).

Some strange things to observe: 

- this delay happens only during file close, while there are much more checks for media changes (every operation on supermount fs does it), the delayed ones are probably just 10% at most

- there is always a READ request being processed between ide_do_drive_cmd and ide_do_request; the actual delay happens between ide_do_drive_cmd and this READ request; I am going to trace all requests to CD_ROM to see when READ is generated

- when I try the above during relatively high disk activity, this usually works normally (i.e. without delays); OTOH when system is mostly idle I get these delays. I have pure IDE system, HD is on one channel, DVD in question on the other. I thought it may be related to DMA (packet commands are run with DMA disabled) but disabling DMA did not change anything.

The problem is old, it existed at least in 2.4.18 that shipped in Mandrake. Currently Mandrake is on 2.4.20 with the same problem.

I will do some tests to pinpoint the place where delays happen; I have not looked at ps output, but if delay happens in ide_do_request, there should not be many possibilities.

Regards

-andrej



             reply	other threads:[~2003-01-08 11:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-08 12:03 Andrey Borzenkov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-12-21  0:49 Problem with read blocking for a long time on /dev/scd1 Gregory 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
2002-12-23  8:58       ` Greg Stark
2002-12-27 15:36         ` Jakob Oestergaard
2003-01-08  4:03         ` Jakob Oestergaard

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=E18WEvi-000Epy-00@f19.mail.ru \
    --to=arvidjaar@mail.ru \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome