linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wojtek Pilorz <wpilorz@bdk.pl>
To: Jochen Siebert <siebert@kawo2.rwth-aachen.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: copying/creating large (>500MB) files results in sluggish behaviour.
Date: Mon, 6 Aug 2001 10:40:58 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.21.0108061031410.14558-100000@celebris.bdk.pl> (raw)
In-Reply-To: <01072317440600.01317@siebert.kawo2.rwth-aachen.de>

On Mon, 23 Jul 2001, Jochen Siebert wrote:

> Date: Mon, 23 Jul 2001 18:10:34 +0000
> From: Jochen Siebert <siebert@kawo2.rwth-aachen.de>
> Reply-To: siebert@physik.rwth-aachen.de
> To: linux-kernel@vger.kernel.org
> Subject: PROBLEM: copying/creating large (>500MB) files results in
>     sluggish behaviour.
> 
> Hi,                     (look at the end of email for data) 
> 
> I´ve got a problem with my linux 2.4.7 box. If I download a 
> large (>500MB) file from a computer connected via 100Mbit 
> LAN (i.e. with more than 2MB/s) *or* I create such a large 
> file via the "dd" command (dd if=/dev/zero of=sloow)
> after some time my computer gets very sluggy and reacts
> veery sloow. I´ve watched the memory usage while creating 
> such a big file and noticed that all memory gets filled up, 
> and even swapping starts, *before* the disk starts to write 
> the file. Ok, so swapping and file writing at once seems to
> be not such a good idea of the kernel, even if the IBM 
> IC35L040 IDE disk is a fast one. Feel free to ask my via 
> email.
> 
> Adies,
> Jochen
> 
> ps: plz cc me.
> 
> Now the facts:
> =============================
[...]
> MemTotal:       384880 kB +128MB Swap,

I can see similar problem with kernels 2.2.x when writing a large amount
of data (compared to size of RAM, of size of free RAM) to a slow media (PD
drive , with write performance of about 250 kBytes/s).

It seems all data is 'cached' before being written, and this can make
system really unusable for the copy time - login from console can take
several minutes.
My understanding is that Linux is too aggressive in caching data to be
written and does not make distinction between fast and slow media;

The only workaround I am aware of is to reduce the speed data is put to
the filesystem (e.g. by using rsync with option --bwlimit)

Best regards,

Wojtek





      reply	other threads:[~2001-08-06  8:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-23 18:10 PROBLEM: copying/creating large (>500MB) files results in sluggish behaviour Jochen Siebert
2001-08-06  8:40 ` Wojtek Pilorz [this message]

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=Pine.LNX.4.21.0108061031410.14558-100000@celebris.bdk.pl \
    --to=wpilorz@bdk.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=siebert@kawo2.rwth-aachen.de \
    /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;
as well as URLs for NNTP newsgroup(s).