From: "war war" <war@starband.net>
To: linux-kernel@vger.kernel.org
Cc: war@starband.net
Subject: Kernel 2.4.16 & Heavy I/O
Date: Thu, 29 Nov 2001 10:46:40 -0500 [thread overview]
Message-ID: <B7F1F9B7DE30EDF47ADB4F8F44CAC84B@war.starband.net> (raw)
Issue:
Is it possible to set the disk cache size to a higher value to avoid
temporary freezing while untarring large files? Memory is not an
issue, I have plenty of it. The disk drive is a good drive, does
29.2MB/s sustained in single user mode, 25MB/s when I have a lot of
processes open. Here is what I think is going on. Sometimes, when I
untar things, or do things that consume a lot of disk space rapidly,
they do it VERY quickly, and then the disk rumbles on for 5-20
seconds after it is done. What accounts for this?
Example:
[20:10]% tar -xf 2GB-FILE.tar
[20:30]% # Hard disk is still grinding.
[20:60]% # Hard disk stops grinding.
In essence, the 'tar' command is finished, however, 30-60 seconds
after it has finished, it is actually still decompressing the data to
the file on the disk.
I have not tested ALL kernels for when or where this has started, but
could someone provide a further explanation as to why the disk
scheduluer works like this?
On Solaris, when I untar a file, the disk stops grinding when the tar
process is finished, and the system is totally usuable.
With Linux, when I untar the file, the system may completely lock up
for 3-5 seconds during the duration after the initial untar (which is
30-60 seconds) after the untar processes has ended.
System Setup: P3/866
1GB RAM
2GB SWAP
Kernel 2.4.16
Result:
Just read this [bottom] after trying to burn 2 CD's (luckily on
CDRW's) at the same time on two different IDE bus controllers while
untarring a 1.6GB file. With earlier kernels, this is usually not a
problem.
CDRW1 = Plextor v1.09
CDRW2 = HP 7510i
Burnproof kicked in for the Plextor, I love Plextor drives.
With the HP, it didn't have enough data to fill the buffer, and
therefore caused a buffer underrun, easy to blank=toc and re-write
however.
http://lwn.net/2001/1129/kernel.php3
The current stable kernel release is 2.4.16. This release, the first
by Marcelo Tosatti, contains little beyond the filesystem fix. This
release does seem to deserve the name "stable," though there are
still some persistent complaints about interactive response in the
presence of heavy I/O. The culprit appears to be the disk I/O
scheduler; a real fix for that problem could be long in coming. The
2.4.17-pre1 prepatch contains a number of items including a new USB
maintainer and a devfs update.
next reply other threads:[~2001-11-29 15:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-29 15:46 war war [this message]
2001-11-29 15:43 ` Blue Lang
2001-11-29 18:01 ` Andrew Morton
2001-11-29 21:42 ` Martin Josefsson
2001-11-30 13:59 ` Helge Hafting
2001-12-05 19:57 ` Pablo Borges
2001-12-05 20:07 ` Roy Sigurd Karlsbakk
2001-12-06 18:06 ` Pablo Borges
2001-12-06 18:10 ` Roy Sigurd Karlsbakk
2001-12-06 18:38 ` Rik van Riel
2001-12-06 19:36 ` Mike Galbraith
2001-12-06 19:56 ` Rik van Riel
2001-12-06 22:50 ` Alan Cox
2001-12-07 5:37 ` Mike Galbraith
2001-12-07 8:43 ` Alan Cox
2001-12-07 21:53 ` Mike Galbraith
2001-12-07 22:02 ` Rik van Riel
2001-12-06 18:28 ` Pablo Borges
2001-12-07 13:46 ` Stephan von Krawczynski
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=B7F1F9B7DE30EDF47ADB4F8F44CAC84B@war.starband.net \
--to=war@starband.net \
--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
all inboxes | Powered by JetHome®